date:20060619

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

james strachan commented on AMQ-758:


I don't really understand the problem. Message Groups are designed so that a 
single thread processes all messages of the same group. If you don't want that, 
don't use message groups.

If you want to allow concurrent processing (multiple threads processing the 
same message group) then you need to use something else.

A fix for your problem would be to just use a separate background thread to do 
the long operation so that the caller can cancel the operation.

e.g.

foo.startLongOperation();

// the above returns without blocking

foo.cancelLongOperation();

That way you can use message groups

 Message Groups disables server side JMS session pooling
 ---

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

   Components: Broker
 Versions: 4.0
  Environment: XP, ActiveMQ 4.0 release, Lingo 1.1, Spring 2.0
 Reporter: Sanjiv Jivan
  Attachments: lingocluster.zip


 Specifying Message Groups on the client causes serialized/ single threaded 
 processing of messages on the server side even when server side session 
 pooling is configured.
 Please find attached  sample code along with a JUnit test MessageGroupTests 
 that demonstrates the issue. My sample is based on Lingo. The client calls an 
 async method solve(scenarioName) and receives progress callbacks. When the 
 cleint calls cancel(scenarioName) during a solve, the cancel method on the 
 server side should be received and stop the running solve. Since a single JMS 
 session evexcutes message listeners serially, I've configured a JMS server 
 session pool of size 20 using Spring's DefaultMessageListenerContainer class.
 I've configured use of a message group via a Lingo marshaller class 
 org.sanjiv.lingo.client.MessageGroupMarshaller. This class basically sets the 
 JMS header  JMSXGroupID to the scenarioName in question so that when a 
 cluster of servers are running, the cancel(scenarioName) call is directed to 
 the server that had solve(scenarioName) called for a given scenarioName.
 The issue is that when the message groups are enabled using the 
 MessageGroupMarshaller, the cancel(scenarioName) call blocks and waits for 
 the async solve(scenarioName) method to complete on the server (which is not 
 the right behaviour). Disabling message groups by commenting out the client 
 side MessageGroupMarshaller marshaller in 
 org/sanjiv/lingo/test/messageGroupContext.xml results in the call being 
 excuted correctly.
 I see that the docs for message groups say that message order is preserved, 
 however that should not require that the second message blocks till the first 
 message completes. Only the order in which the listeners are executes should 
 be guaranteed to be the order of message receipt.
 Let me know if you have any questions.

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

[jira] Resolved: (AMQ-758) Message Groups disables server side JMS session pooling

 [ https://issues.apache.org/activemq/browse/AMQ-758?page=all ]
 
james strachan resolved AMQ-758:


Resolution: Won't Fix

Closed for now as this bug is an effect of the design of Message Groups - they 
are meant to implement single-threaded processing of a single message group.

 Message Groups disables server side JMS session pooling
 ---

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

   Components: Broker
 Versions: 4.0
  Environment: XP, ActiveMQ 4.0 release, Lingo 1.1, Spring 2.0
 Reporter: Sanjiv Jivan
  Attachments: lingocluster.zip


 Specifying Message Groups on the client causes serialized/ single threaded 
 processing of messages on the server side even when server side session 
 pooling is configured.
 Please find attached  sample code along with a JUnit test MessageGroupTests 
 that demonstrates the issue. My sample is based on Lingo. The client calls an 
 async method solve(scenarioName) and receives progress callbacks. When the 
 cleint calls cancel(scenarioName) during a solve, the cancel method on the 
 server side should be received and stop the running solve. Since a single JMS 
 session evexcutes message listeners serially, I've configured a JMS server 
 session pool of size 20 using Spring's DefaultMessageListenerContainer class.
 I've configured use of a message group via a Lingo marshaller class 
 org.sanjiv.lingo.client.MessageGroupMarshaller. This class basically sets the 
 JMS header  JMSXGroupID to the scenarioName in question so that when a 
 cluster of servers are running, the cancel(scenarioName) call is directed to 
 the server that had solve(scenarioName) called for a given scenarioName.
 The issue is that when the message groups are enabled using the 
 MessageGroupMarshaller, the cancel(scenarioName) call blocks and waits for 
 the async solve(scenarioName) method to complete on the server (which is not 
 the right behaviour). Disabling message groups by commenting out the client 
 side MessageGroupMarshaller marshaller in 
 org/sanjiv/lingo/test/messageGroupContext.xml results in the call being 
 excuted correctly.
 I see that the docs for message groups say that message order is preserved, 
 however that should not require that the second message blocks till the first 
 message completes. Only the order in which the listeners are executes should 
 be guaranteed to be the order of message receipt.
 Let me know if you have any questions.

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

[jira] Assigned: (AMQ-757) MapMessage to support nested Map objects to create a typesafe hierarchial message such as used on RV etc

 [ https://issues.apache.org/activemq/browse/AMQ-757?page=all ]

james strachan reassigned AMQ-757:
--

Assign To: james strachan

 MapMessage to support nested Map objects to create a typesafe hierarchial 
 message such as used on RV etc
 

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

 Versions: 4.0
 Reporter: james strachan
 Assignee: james strachan
  Fix For: 4.1





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

[jira] Commented: (AMQ-719) OpenWire ActiveMQTextMessage not sharable between JMS client and dotNet client

2006-06-19 Thread James Stanton (JIRA)

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

James Stanton commented on AMQ-719:
---

This can be fixed by changing ActiveMQTextMessage Text getter/setter to look 
like this:  (tested with Java 1.4.2)

public string Text
{
get {
if (text == null)
{
// now lets read the content
byte[] data = this.Content;
if (data != null)
{
// TODO assume that the text is ASCII
char[] chars = new char[data.Length - sizeof(int)];
for (int i = 0; i  chars.Length; i++)
{
chars[i] = (char)data[i + sizeof(int)];
}
text = new String(chars);
}
}
return text;
}

set {
this.text = value;
byte[] data = null;
if (text != null)
{
// TODO assume that the text is ASCII
byte[] intData = System.BitConverter.GetBytes(text.Length);
data = new byte[text.Length + intData.Length];  //int at 
the front of it
char[] chars = text.ToCharArray();

for (int j = 0; j  intData.Length; j++)
{
data[j] = intData[intData.Length - j - 1];  //reverse 
byte order, I'm not certain why this is necessary, but it is -Jamie
}

for (int i = 0; i  chars.Length; i++)
{
data[i + intData.Length] = (byte)chars[i];
}
}
this.Content = data;
}
}




Hope this helps.

Jamie

 OpenWire ActiveMQTextMessage not sharable between JMS client and dotNet client
 --

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

   Components: JMS client
 Versions: 4.0
  Environment: ActiveMQ incubator 4.0 release - windows xp pro - jdk1.5 - 
 dotNet2003 - openwire dotnet client from svn head
 Reporter: James Bradt
  Fix For: 4.1, 4.0.2



 The payload content for a JMS message contains initial bytes for the length 
 of the text string.  The payload content for an dotNet openwire content does 
 not contain this information.  This mismatch in payload results in invalid 
 payloads when passing jms messages between technologies.

-- 
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: build failure with latest source: maven-jetty6-plugin

2006-06-19 Thread Guillaume Nodet


This plugin is available on public repos, so you may try again to run maven
until
is successfully download all the needed dependencies.
See
http://repo.mergere.com/maven2/org/mortbay/jetty/maven-jetty6-plugin/6.0.0beta17/

Cheers,
Guillaume Nodet

On 6/16/06, David Black [EMAIL PROTECTED] wrote:


Hi,

With the latest src from here:

http://svn.apache.org/repos/asf/incubator/servicemix/trunk/

and with maven 2.0.4 doing a

mvn eclipse:eclipse

in the root folder, I am having a build problem so:

[ERROR] BUILD ERROR
[INFO]

[INFO] The plugin 'org.mortbay.jetty:maven-jetty6-plugin' does not exist
or
no valid version could be found

I've grabbed

maven-jetty6-plugin-6.0.0beta9.jar

manually, and placed it with that name and also as

maven-jetty6-plugin.jar

into my m2 repository at this location:

.m2\repository\org\mortbay\jetty\maven-jetty6-plugin

The build failure persists. Anyone else having / had this problem? I'm not
so familiar with maven2 so maybe I'm confused ... but I assume the code
should build from subversion, and I'm following the instructions from
here:

http://www.servicemix.org/site/building.html

Any help much appreciated

thanks

David Black
http://radio.weblogs.com/0146416/

Re: src for BPEL-Example

2006-06-19 Thread manuella


Thanks!
I've checked that.
--
View this message in context: 
http://www.nabble.com/src-for-BPEL-Example-t1791958.html#a4934663
Sent from the ServiceMix - Dev forum at Nabble.com.

Re: Updated 1.1 Release Binaries

2006-06-19 Thread Jacek Laskowski


On 6/19/06, Matt Hogstrom [EMAIL PROTECTED] wrote:


No other changes were made to the 1.1.0 branch.  I have rebuilt the server and 
provided updated
links to them below.

*DayTrader Application*
http://people.apache.org/~hogstrom/1.1-final2/daytrader-ear-1.1-final2.ear

I'm working on a website and documentation to help folks out but the 
deliverable is the ear above.

*Geronimo 1.1 Version*

*Source*
  
http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1-final2_src.tar.gz
  http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1-final2_src.zip

*Full J2EE Jetty Version*
  
http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-j2ee-1.1-final2.tar.gz
  
http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-j2ee-1.1-final2.zip

*Minimal Jetty Version*
  
http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-minimal-1.1-final2.tar.gz
  
http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-minimal-1.1-final2.zip

*Full Tomcat Version*
  
http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-j2ee-1.1-final2.tar.gz
  
http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-j2ee-1.1-final2.zip

*Minimal Tomcat Version*
  
http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-minimal-1.1-final2.tar.gz
  
http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-minimal-1.1-final2.zip


Just to warn others before they rise it up - the urls above are
invalid as they don't contain final-2 in their names (note the hyphen
between final and 2).


At what point is the vote called and the distribution allowed?


I think it should have started with your announcement the latest
builds were available. I'd change the title of the message to begin
with [VOTE] and resent. Since the above urls are broken it would make
others' lifes easier, too ;-)


Matt


Jacek

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

[jira] Created: (GERONIMO-2136) Remove/Update licenses displayed in about page of console

2006-06-19 Thread John Sisson (JIRA)

Remove/Update licenses displayed in about page of console
-

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


The licenses displayed in the console in the about page ( 
http://localhost:8080/console/about.jsp ) are a subset of those in Geronimo's 
LICENSE.txt file.

Either this licenses on this page should be removed or they should be updated 
to match the LICENSE.txt file.

See mail thread.

http://www.mail-archive.com/dev%40geronimo.apache.org/msg24852.html

-- 
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: (AMQ-747) Redelivery backoff should add random delay for collision avoidance

 [ https://issues.apache.org/activemq/browse/AMQ-747?page=all ]
 
james strachan resolved AMQ-747:


Resolution: Fixed

Patch applied - many thanks!

(we just missed 4.0.1 but will try release 4.1 real soon).



 Redelivery backoff should add random delay for collision avoidance
 --

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

   Components: Connector
 Versions: 4.0
 Reporter: Christopher G. Stach II
  Fix For: 4.1
  Attachments: AMQ-747.patch


 If a rollback on two messages happens between three transactional deliveries, 
 and the two messages are redelivered with the same redelivery backoff 
 settings, there is a likelihood that both messages will cause another 
 rollback to happen.  If maximumRedeliveries is set too low, or there are a 
 maximumRedeliveries + 1 messages coming in simultaneously, messages may never 
 get delivered.  Can we get another option for the clients that adds a random 
 backoff delay adjustment in addition to the constant backoff delay factor?  
 This would end up working like most other collision avoidance algorithms.

-- 
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: Wiki based FAQ

2006-06-19 Thread Sachin Patel


+1

On Jun 16, 2006, at 6:19 PM, Dain Sundstrom wrote:

I put together a FAQ in the sandbox on the cwiki.  I seeded it with  
content from the main wiki on the Geronimo website and with some  
content from a resent email I sent about accessing an MBean server  
from a GBean.


This is just an idea, and I will have no hard feelings if we decide  
to delete it (it only took 20 minutes to get going).


http://cwiki.apache.org/confluence/display/GMOxSBOX/FAQ

What do you think?

-dain



-sachin

[jira] Resolved: (AMQ-753) exposing the client IP Address

 [ https://issues.apache.org/activemq/browse/AMQ-753?page=all ]
 
james strachan resolved AMQ-753:


Fix Version: 4.1
 Resolution: Fixed

Patch applied - many thanks!

 exposing the client IP Address
 --

  Key: AMQ-753
  URL: https://issues.apache.org/activemq/browse/AMQ-753
  Project: ActiveMQ
 Type: New Feature

   Components: Broker
 Versions: 4.0
  Environment: all os.
 Reporter: Ramesh Bobba
  Fix For: 4.1
  Attachments: AMQ-753.patch


 We have a requirement to validate a client's host when a subscription request 
 is performed. Is there a way to do this? If not, can we add this?

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

[jira] Commented: (AMQ-758) Message Groups disables server side JMS session pooling

2006-06-19 Thread Sanjiv Jivan (JIRA)

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

Sanjiv Jivan commented on AMQ-758:
--

Makes sense. I'll use the pooled executor from the concurrent library.

 Message Groups disables server side JMS session pooling
 ---

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

   Components: Broker
 Versions: 4.0
  Environment: XP, ActiveMQ 4.0 release, Lingo 1.1, Spring 2.0
 Reporter: Sanjiv Jivan
  Attachments: lingocluster.zip


 Specifying Message Groups on the client causes serialized/ single threaded 
 processing of messages on the server side even when server side session 
 pooling is configured.
 Please find attached  sample code along with a JUnit test MessageGroupTests 
 that demonstrates the issue. My sample is based on Lingo. The client calls an 
 async method solve(scenarioName) and receives progress callbacks. When the 
 cleint calls cancel(scenarioName) during a solve, the cancel method on the 
 server side should be received and stop the running solve. Since a single JMS 
 session evexcutes message listeners serially, I've configured a JMS server 
 session pool of size 20 using Spring's DefaultMessageListenerContainer class.
 I've configured use of a message group via a Lingo marshaller class 
 org.sanjiv.lingo.client.MessageGroupMarshaller. This class basically sets the 
 JMS header  JMSXGroupID to the scenarioName in question so that when a 
 cluster of servers are running, the cancel(scenarioName) call is directed to 
 the server that had solve(scenarioName) called for a given scenarioName.
 The issue is that when the message groups are enabled using the 
 MessageGroupMarshaller, the cancel(scenarioName) call blocks and waits for 
 the async solve(scenarioName) method to complete on the server (which is not 
 the right behaviour). Disabling message groups by commenting out the client 
 side MessageGroupMarshaller marshaller in 
 org/sanjiv/lingo/test/messageGroupContext.xml results in the call being 
 excuted correctly.
 I see that the docs for message groups say that message order is preserved, 
 however that should not require that the second message blocks till the first 
 message completes. Only the order in which the listeners are executes should 
 be guaranteed to be the order of message receipt.
 Let me know if you have any questions.

-- 
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: Licenses displayed in console

I think the best bet is to point the user to the LICENSE.txt file as  well as the NOTICES.txt file. 
 Or alternately, we can read these files and display them.  Since we have the correct license files 
in the build I'd prefer to defer a solution to this until 1.1.1.


Aaron Mulder wrote:

I'm not sure we really need a license screen in the console -- it
seems unlikely to always be up to date.  But if we do want it, we
should probably update it with everything in LICENSE.txt.

Thanks,
   Aaron

On 6/18/06, Matt Hogstrom [EMAIL PROTECTED] wrote:
I'm not sure of the correct answer to that.  The console cannot always 
display the licenses about
third party software that has been installed.  I would think that it 
should display the licenses

that shipped with Geronimo.

Others thoughts?

John Sisson wrote:
 Are the licenses displayed in the console in the about page (
 http://localhost:8080/console/about.jsp ) meant to represent the whole
 of Geronimo, or just the console?

 Currently the licenses displayed there are a subset of those in
 Geronimo's LICENSE.txt file.

 John

[jira] Updated: (GERONIMO-2067) Configs migration to M2

2006-06-19 Thread Anita Kulshreshtha (JIRA)

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

Anita Kulshreshtha updated GERONIMO-2067:
-

Attachment: m2-plugins.patch
configs.patch
configs.log

These patches modify geronimo packaging plugin to add geronimo-plugin.xml to 
the generated car and
handle multiple artifacts genearated by the daytrader configuration. The 
configs.patch adds daytrader configuration for jetty and tomcat.
1. m2-plugins.patch
2. configs.patch
3. configs.log -  results for rev. 414318
4. etc.patch - attached earlier 
 A brief description of the changes to the plugin - 
Plugin takes a parameter 'geronimoPlugin' (true), and by default uses 
src/conf/geronimo-plugin.xml. 
This file is filtered and packaged in the car.
   The daytrader configuration generates multiple artifacts. Plugin takes 
multipleArtifacts (true) as a parameter
to generate attached artifacts. For configurations that generate multiple 
artifacts, the target/repository/${groupId}/ directory is scanned for the 
artifacts generated by the deployer. All the artifacts are zipped to target 
directory and installed using attached artifacts. Maven restricts the name of 
the artifacts to be - 
${artifactId}-${version}-classifier.car
I prefer ${artifactId}-classifier-${version}.car. I have filed an issue - 
http://jira.codehaus.org/browse/MNG-2395
   Also filed issues to exclude pom.xml and pom.properties for war and rar 
files generated by maven
http://jira.codehaus.org/browse/MPWAR-59
http://jira.codehaus.org/browse/MRAR-10


 Configs migration to M2
 ---

  Key: GERONIMO-2067
  URL: http://issues.apache.org/jira/browse/GERONIMO-2067
  Project: Geronimo
 Type: Sub-task
 Security: public(Regular issues) 
   Components: buildsystem
 Versions: 1.2
  Environment: All
 Reporter: Anita Kulshreshtha
 Assignee: Anita Kulshreshtha
  Fix For: 1.2
  Attachments: configs.log, configs.log, configs.log, configs.patch, 
 configs.patch, configs.patch, configs.patch, configs.patch, etc.patch, 
 m2-plugins.patch, modules.patch, modules.patch, newconfigs.patch, pom.patch, 
 pom.patch, pom.patch

 To build these configurations use packaging plugin GERONIMO-1740. This patch 
 builds non openejb and non jetty configurations. 
 This patch is for the new trunk, and has been edited using emcas to rempve ^M.

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

M2 : Build Instruction

2006-06-19 Thread anita kulshreshtha

Hi All, 
   I was looking for a suitable place to add the build instrucitons for
M2. I could not find any section dealing with the trunk at
http://cwiki.apache.org/geronimo/
  
Thanks
Anita  

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

[jira] Updated: (GERONIMO-2135) Improve the ActiveMQ GBeans

2006-06-19 Thread Hiram Chirino (JIRA)

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

Hiram Chirino updated GERONIMO-2135:


Attachment: GERONIMO-2135.patch

Fixes most of the items in this issue.

 Improve the ActiveMQ GBeans
 ---

  Key: GERONIMO-2135
  URL: http://issues.apache.org/jira/browse/GERONIMO-2135
  Project: Geronimo
 Type: Improvement
 Security: public(Regular issues) 
   Components: ActiveMQ
 Reporter: Hiram Chirino
 Assignee: Hiram Chirino
  Fix For: 1.2
  Attachments: GERONIMO-2135.patch

 Suggestions by David Jencks:
 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.

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

[RTC] http://issues.apache.org/jira/browse/GERONIMO-2135

2006-06-19 Thread Hiram Chirino


Hi folks,

Looking for 3 +1s for the patch attached to
http://issues.apache.org/jira/browse/GERONIMO-2135.
This patch addresses previous concerns raised by David Jencks.

Items not addressed by the patch are:

#4: yes. I agree, but since these GBeans are just meant to be a simple
integration between Geronimo and ActiveMQ, we are taking some short
cuts.  In general ActiveMQ allows you to configure many more options
than what the current GBeans allows you to do.

#5, I also agree, but I don't have a programmatic way of listing all
protocols since they are loaded by searching the classpath for
META-INF resources.

--
Regards,
Hiram

Blog: http://hiramchirino.com

Re: [CONSENSUS] Default plugin site (was Re: Frustrations of a Release Manager)

2006-06-19 Thread Paul McMahan


There's an interesting plugin site for eclipse at
eclipseplugincentral.com that implements some of the ideas we have
discussed.  It provides a directory of plugins but not the actual
files themselves, pointing elsewhere for the purchase/download.  It
also provides a rating system, news page, and discussion forums.  IMHO
the geronimo project should strive to provide this type of site for
building a healthy commercial and open source community around
geronimo plugins.

The domain names geronimoplugincentral.com and
geronimoplugincentral.org were available and match the form used by
eclipseplugincentral.com so I purchased them and would like to
donate them to the ASF.  How can I do that?  Just send a note to
[EMAIL PROTECTED]

Best wishes,
Paul


On 6/14/06, David Blevins [EMAIL PROTECTED] wrote:

Everyone, please read and ACK.

On Jun 14, 2006, at 4:31 PM, John Sisson wrote:

 Hiram, I care if a private or commercial entity has control over
 the default option.

I think Hiram does too, he just a read a little too fast.  His
thoughts are clear though.

On Jun 14, 2006, at 3:55 PM, Hiram Chirino wrote:
 All I'm saying is I don't care if IBM puts up
 http://www.ibm.com/wasce/plugins, I also don't care if you put up a
 http://virtuas.com/geronimo/plugins site.

 Now the default link issue is something else.  Can we point it by
 default at some Apache machines by default?  I'm sure Aaron would not
 mind, would you?

That pretty much sums it up for me.  Aaron seems to agree.  In fact,
is there anyone out there who doesn't agree?

-David

[jira] Created: (GERONIMO-2137) Empty datasource tracefile causes fatal error attempting to run web app

2006-06-19 Thread Tim Pickett (JIRA)

Empty datasource tracefile causes fatal error attempting to run web app
---

 Key: GERONIMO-2137
 URL: http://issues.apache.org/jira/browse/GERONIMO-2137
 Project: Geronimo
Type: Bug
Security: public (Regular issues) 
  Components: databases  
Versions: 1.0
 Environment: Issue was found on Windows, but unsure if it is limited to 
Windows server 2003.
Reporter: Tim Pickett


If you deploy a web applicaiton with a datasource(db2 in this instance) and do 
not specify a tracefile, the application will run fine.  Once you use the admin 
console to change an attribute in the datasource, the application server will 
add an empty tracefile attribute to the config.xml, and you will no longer be 
able to run the web application if it attempt so access the database.  (Issue 
was found in CE)

WORKAROUND: remove the 2 attributes from the config.xml and it will work fine, 
no attempt to trace occurs.

The attributes added are:
  attribute name=TraceFile/attribute
  attribute name=TraceFileAppendfalse/attribute

The entire section of the config.xml file for the datasource is as follows:

configuration name=Trade
gbean 
name=geronimo.server:J2EEApplication=Trade,J2EEServer=geronimo,JCAResource=TradeDataSource,j2eeType=JCAManagedConnectionFactory,name=jdbc/TradeDataSource
  attribute name=DatabaseNametradev/attribute
  attribute name=Usertrade/attribute
  attribute name=DriverType4/attribute
  attribute 
name=Password{Simple}rO0ABXNyABlqYXZheC5jcnlwdG8uU2VhbGVkT2JqZWN0PjY9psO3VHACAARbAA1lbmNvZGVkUGFyYW1zdAACW0JbABBlbmNyeXB0ZWRDb250ZW50cQB+AAFMAAlwYXJhbXNBbGd0ABJMamF2YS9sYW5nL1N0cmluZztMAAdzZWFsQWxncQB+AAJ4cHB1cgACW0Ks8xf4BghU4AIAAHhwECL7hrKO7YATsIUlVrzQ9VxwdAADQUVT/attribute
  attribute name=PortNumber5/attribute
  attribute name=ServerNameviper22/attribute
  attribute name=TraceFile/attribute
  attribute name=TraceFileAppendfalse/attribute
/gbean
gbean 
name=geronimo.server:J2EEApplication=Trade,J2EEServer=geronimo,JCAResource=TradeDataSource,j2eeType=JCAConnectionManager,name=jdbc/TradeDataSource
  attribute name=partitionMinSize0/attribute
  attribute name=partitionMaxSize40/attribute
  attribute name=blockingTimeoutMilliseconds5000/attribute
  attribute name=idleTimeoutMinutes30/attribute
/gbean
  /configuration

Stack trace follows:

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fswiss\fcharset0 Arial;}}
{\*\generator Msftedit 5.41.21.2500;}\viewkind4\uc1\pard\f0\fs20 
com.ibm.db2.jcc.a.SqlException: Unable to open file\par
at com.ibm.db2.jcc.a.xd.a(xd.java:93)\par
at 
com.ibm.db2.jcc.DB2BaseDataSource.computePrintWriter(DB2BaseDataSourc\par
e.java:1955)\par
at 
com.ibm.db2.jcc.DB2BaseDataSource.computeJccLogWriter(DB2BaseDataSour\par
ce.java:1848)\par
at 
com.ibm.db2.jcc.DB2BaseDataSource.computeJccLogWriterForNewConnection\par
(DB2BaseDataSource.java:1808)\par
at 
com.ibm.db2.jcc.DB2BaseDataSource.computeJccLogWriterForNewConnection\par
(DB2BaseDataSource.java:1768)\par
at 
com.ibm.db2.jcc.DB2XADataSource.getXAConnection(DB2XADataSource.java:\par
62)\par
at 
org.tranql.connector.jdbc.AbstractXADataSourceMCF.getPhysicalConnecti\par
on(AbstractXADataSourceMCF.java:74)\par
at 
org.tranql.connector.db2.XAMCF.createManagedConnection(XAMCF.java:57)\par
\par
at 
org.apache.geronimo.connector.outbound.MCFConnectionInterceptor.getCo\par
nnection(MCFConnectionInterceptor.java:41)\par
at 
org.apache.geronimo.connector.outbound.XAResourceInsertionInterceptor\par
.getConnection(XAResourceInsertionInterceptor.java:41)\par
at 
org.apache.geronimo.connector.outbound.SinglePoolConnectionIntercepto\par
r.internalGetConnection(SinglePoolConnectionInterceptor.java:63)\par
at 
org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionIn\par
terceptor.getConnection(AbstractSinglePoolConnectionInterceptor.java:73)\par
at 
org.apache.geronimo.connector.outbound.TransactionEnlistingIntercepto\par
r.getConnection(TransactionEnlistingInterceptor.java:47)\par
at 
org.apache.geronimo.connector.outbound.TransactionCachingInterceptor.\par
getConnection(TransactionCachingInterceptor.java:86)\par
at 
org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.ge\par
tConnection(ConnectionHandleInterceptor.java:43)\par
at 
org.apache.geronimo.connector.outbound.TCCLInterceptor.getConnection(\par
TCCLInterceptor.java:39)\par
at 
org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor.\par
getConnection(ConnectionTrackingInterceptor.java:66)\par
at 
org.apache.geronimo.connector.outbound.AbstractConnectionManager.allo\par
cateConnection(AbstractConnectionManager.java:57)\par
at 
org.tranql.connector.jdbc.DataSource.getConnection(DataSource.java:56\par
)\par
at

[jira] Created: (XBEAN-21) org\apache\xbean\spring\context\XmlWebApplicationContext.java does not work

2006-06-19 Thread Guillaume Nodet (JIRA)

org\apache\xbean\spring\context\XmlWebApplicationContext.java does not work
---

 Key: XBEAN-21
 URL: http://issues.apache.org/jira/browse/XBEAN-21
 Project: XBean
Type: Bug

  Components: spring  
Versions: 2.4
Reporter: Guillaume Nodet
 Assigned to: Guillaume Nodet 
 Fix For: 2.5




-- 
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: Do we need a Plugin Repo at the ASF ?

2006-06-19 Thread Donald Woods

Aaron, I'd also like to help maintain the geronimoplugins website and 
work on providing patches to enable building all of the samples and 
configurations needed to upgrade a minimal-server to a full J2EE server.


-Donald


Matt Hogstrom wrote:



Rodent of Unusual Size wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matt Hogstrom wrote:


If others feel that it needs to be at Apache *AND* are willing to set
it up then this is the time to speak up.



If 'it' is singular, then having 'it' hosted at Apache means
only Apache-licensed plugins can go into it.  No GPL or
LGPL or others..

Based on that I think sticking with 'it' being geronimoplugins.com
(although .org might be/have been better) makes sense.  When
the Geronimo project has a significant number -- like, say, a
dozen or so -- then having an ASF repo for them might be worth
revisiting.



I'm of the same mind that we don't have enough content to warrant the 
churn to create the resources at Apache now.


I think there are lots of good ideas but Aaron did create the code and 
make it work so I'll give him credit for that effort.  The point of this 
thread is to identify people that want to work on the plugin repo at 
Apache and I don't think we've found them yet :)




For now let's stick with geronimoplugins.com -- but make sure
the code can handle a *list* of repositories.
- --
#kenP-)}

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

Millennium hand and shrimp!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRJKE0ZrNPMCpn3XdAQJnzwP/SaS+1r994T8VJ6VvGD+deCod/GCZs8b5
+6MfKXvjgPqg6dRPKfvrGn8UblnhT0WL+/0kZH1+230/fWmM5ngMLCIS3c/cxvmP
8M53v2UD6JPtLfyos6wgOc9bLe5JKGSbqRJms8TAIXBiX+csjC1huHqfitRyvgp/
DdtgCZFEIzw=
=01nm
-END PGP SIGNATURE-








smime.p7s
Description: S/MIME Cryptographic Signature

Re: [CONSENSUS] Default plugin site (was Re: Frustrations of a Release Manager)

2006-06-19 Thread Jeff Genender

+1 great idea Paul.

Paul McMahan wrote:
 There's an interesting plugin site for eclipse at
 eclipseplugincentral.com that implements some of the ideas we have
 discussed.  It provides a directory of plugins but not the actual
 files themselves, pointing elsewhere for the purchase/download.  It
 also provides a rating system, news page, and discussion forums.  IMHO
 the geronimo project should strive to provide this type of site for
 building a healthy commercial and open source community around
 geronimo plugins.
 
 The domain names geronimoplugincentral.com and
 geronimoplugincentral.org were available and match the form used by
 eclipseplugincentral.com so I purchased them and would like to
 donate them to the ASF.  How can I do that?  Just send a note to
 [EMAIL PROTECTED]
 
 Best wishes,
 Paul
 
 
 On 6/14/06, David Blevins [EMAIL PROTECTED] wrote:
 Everyone, please read and ACK.

 On Jun 14, 2006, at 4:31 PM, John Sisson wrote:

  Hiram, I care if a private or commercial entity has control over
  the default option.

 I think Hiram does too, he just a read a little too fast.  His
 thoughts are clear though.

 On Jun 14, 2006, at 3:55 PM, Hiram Chirino wrote:
  All I'm saying is I don't care if IBM puts up
  http://www.ibm.com/wasce/plugins, I also don't care if you put up a
  http://virtuas.com/geronimo/plugins site.
 
  Now the default link issue is something else.  Can we point it by
  default at some Apache machines by default?  I'm sure Aaron would not
  mind, would you?

 That pretty much sums it up for me.  Aaron seems to agree.  In fact,
 is there anyone out there who doesn't agree?

 -David

Re: [VOTE] 1.1 Release

2006-06-19 Thread Hernan Cunico

John Sisson wrote:

Some notes in relation to documentation:

* Clicking on the the Geronimo Documentation link on
http://myhost:8080/ takes me to
http://geronimo.apache.org/documentation.html which doesn't currently
have any 1.1 documentation. What are the plans for the 1.1 documentation?

I'm planning to update the web site today so it will point to the new cwiki with the 1.0 and 1.1
(inprogress) documentation

* Clicking on the Additional Documentation link on http://myhost:8080/
takes me to
http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Home
which contains a warning that the documentation has moved to
http://cwiki.apache.org/geronimo . Are we planning on changing this to
take users directly to http://cwiki.apache.org/geronimo ?

Additional Documentation is using a redirect
(http://geronimo.apache.org/redirects/additionalDocumentation.html) to point to the Atlassian
confluence. Fixing this redirect is part of the web site update.

I just froze (for edit) the confluence installation at Atlassian so we will not have more adds there
(wanted or unwanted). I've been adding labels to some pages on that installation to point to the new
cwiki.apache.org/geronimo. As far as I know, we can not add an automatic redirect directly from a
confluence page.

Cheers!
Hernan

Other comments in-line below..

I'm still kicking the tires..

John

Matt Hogstrom wrote:

All,

I have created what I hope is the final release of Geronimo 1.1.
There has been a lot of work that has gone into this release (please
review the RELEASE-NOTES). Here are the final release candidates for
your review.

*DayTrader Application*
http://people.apache.org/~hogstrom/1.1-final/daytrader-ear-1.1.ear

I'm working on a website and documentation to help folks out but the
deliverable is the ear above.

*Geronimo 1.1 Version*

*Source*
http://people.apache.org/~hogstrom/1.1-final/geronimo-1.1_src.tar.gz
http://people.apache.org/~hogstrom/1.1-final/geronimo-1.1_src.zip

*Full J2EE Jetty Version*

http://people.apache.org/~hogstrom/1.1-final/geronimo-jetty-j2ee-1.1.tar.gz

http://people.apache.org/~hogstrom/1.1-final/geronimo-jetty-j2ee-1.1.zip

*Minimal Jetty Version*

http://people.apache.org/~hogstrom/1.1-final/geronimo-jetty-minimal-1.1.tar.gz

http://people.apache.org/~hogstrom/1.1-final/geronimo-jetty-minimal-1.1.zip

*Full Tomcat Version*

http://people.apache.org/~hogstrom/1.1-final/geronimo-tomcat-j2ee-1.1.tar.gz

http://people.apache.org/~hogstrom/1.1-final/geronimo-tomcat-j2ee-1.1.zip

*Minimal Tomcat Version*

http://people.apache.org/~hogstrom/1.1-final/geronimo-tomcat-minimal-1.1.tar.gz

http://people.apache.org/~hogstrom/1.1-final/geronimo-tomcat-minimal-1.1.zip

*Geronimo 1.1 Source Code*

FYI (in case you re-use this mail) the line above should read *Geronimo
1.1 Specs*

http://people.apache.org/~hogstrom/1.1-final/org.apache.geronimo.specs.tar.gz

http://people.apache.org/~hogstrom/1.1-final/org.apache.geronimo.specs.zip

Is there are reason why the specs distributions don't have a version in
their file name? Shouldn't it be 1.0.1?

Please remember that only PMC votes are binding but they will
ultimately make their decision based on your feedback.

Thanks to everyone who has spent long hours working on this.

A special thanks to Jencks, Sisson and Miller who spent long days
working on getting the final release right with License issues, last
minute release note changes, etc.

I look forward to a positive outcome and a unanimous vote by Sunday.
Assuming all goes well by Sunday night I will propogate the jars to
the mirrors on Sunday and declare the release official on Tuesday.

Cross your fingers, grab your beverage of choice and let's close this
release out.

Matt

RE: [jira] Commented: (GERONIMO-1046) ORA-00920 SQL Exception thrown when testing day trader with Oracle

2006-06-19 Thread Zakharov, Vasily M

Matt,

What do you mean by plans you corrected?

And by select for update we need to be able to specify?

 Vasily


-Original Message-
From: Matt Hogstrom [mailto:[EMAIL PROTECTED] 
Sent: Saturday, June 17, 2006 5:48 AM
To: dev@geronimo.apache.org
Subject: Re: [jira] Commented: (GERONIMO-1046) ORA-00920 SQL Exception
thrown when testing day trader with Oracle

Thanks Vasily,

I have corrected the plans.  How are the plans going for Oracle?  I
think that we need to be able to 
specify select for update to achieve the right consistency level for
SPECj2004.  Curious what your 
feedback is.

Vasily Zakharov (JIRA) wrote:
 [
http://issues.apache.org/jira/browse/GERONIMO-1046?page=comments#action_
12416551 ] 
 
 Vasily Zakharov commented on GERONIMO-1046:
 ---
 
 There's a typo in this bug's resolution - the package name for
ejb-ql-compiler-factory is org.tranql.ejbQLcompiler.
 
 So the right line would be:
 

ejb-ql-compiler-factoryorg.tranql.ejbqlcompiler.OracleEJBQLCompilerFac
tory/ejb-ql-compiler-factory
 
 
 ORA-00920 SQL Exception thrown when testing day trader with Oracle
 --

  Key: GERONIMO-1046
  URL: http://issues.apache.org/jira/browse/GERONIMO-1046
  Project: Geronimo
 Type: Bug
 Security: public(Regular issues) 
 Versions: 1.0
  Environment: All
 Reporter: Matt Hogstrom
 Assignee: Matt Hogstrom
  Fix For: 1.0
 
 The following exception occurs when running day trader with Oracle:
 15:54:36,575 WARN  [/trade] /trade/app: java.rmi.RemoteException:
Unable to commit container transaction; nested exception is:
 javax.transaction.SystemException: Unable to commit container
transaction
 at
org.openejb.proxy.EJBMethodInterceptor.intercept(EJBMethodInterceptor.ja
va(Compiled Code))
 at
org.openejb.proxy.SessionEJBObject$$EnhancerByCGLIB$$c46b8cb8.login(gen
erated)
 at
org.apache.geronimo.samples.daytrader.TradeAction.login(TradeAction.java
:421)
 at
org.apache.geronimo.samples.daytrader.web.TradeServletAction.doLogin(Tra
deServletAction.java:341)
 at
org.apache.geronimo.samples.daytrader.web.TradeAppServlet.performTask(Tr
adeAppServlet.java:124)
 at
org.apache.geronimo.samples.daytrader.web.TradeAppServlet.doPost(TradeAp
pServlet.java:86)
 at
javax.servlet.http.HttpServlet.service(HttpServlet.java:615)
 at
javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
 at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427)
 at
org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.j
ava:99)
 at
org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(Web
ApplicationHandler.java:830)
 at
org.apache.geronimo.samples.daytrader.web.OrdersAlertFilter.doFilter(Ord
ersAlertFilter.java:84)
 at
org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(Web
ApplicationHandler.java:821)
 at
org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171)
 at
org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(
 WebApplicationHandler.java:821)
 at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicati
 onHandler.java:471)
 at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:5
 68)
 at org.mortbay.http.HttpContext.handle(HttpContext.java:1565)
 at
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplication
 Context.java:635)
 at org.mortbay.http.HttpContext.handle(HttpContext.java:1517)
 at org.mortbay.http.HttpServer.service(HttpServer.java:954)
 at
org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
 at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983)
 at
org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
 at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:
 244)
 at
org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
 at
org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
 Caused by: javax.transaction.SystemException: Unable to commit
container transac
 tion
 at
org.apache.geronimo.transaction.context.InheritableTransactionContext
 .rollbackAndThrow(InheritableTransactionContext.java:327)
 at
org.apache.geronimo.transaction.context.InheritableTransactionContext
 .complete(InheritableTransactionContext.java(Compiled Code))
 at
org.apache.geronimo.transaction.context.InheritableTransactionContext
 .commit(InheritableTransactionContext.java(Compiled Code))
 at
org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPo
 licy.java(Compiled Code))
 at
org.openejb.transaction.TransactionContextInterceptor.invoke(Transact
 ionContextInterceptor.java(Compiled Code))
 at

Re: Do we need a Plugin Repo at the ASF ?

2006-06-19 Thread Aaron Mulder


On 6/19/06, Donald Woods [EMAIL PROTECTED] wrote:

Aaron, I'd also like to help maintain the geronimoplugins website and
work on providing patches to enable building all of the samples and
configurations needed to upgrade a minimal-server to a full J2EE server.


OK.  I've actually got a tool now to generate the web site from the
set of available plugins, so the web site maintenance is less onerous.
So in the short term, it would be great to work on getting the
upgrade plugin together.  Basically, you need to:

- create a geronimo-plugin.xml with a name and description and stuff
but no module ID (you can refer to the plugins-1.1.xsd schema)
- add all the needed CARs (the ones in the J2EE server but not the
minimal server) as dependencies
- list the unavailable module builders as obsoletes

To try this out, the easiest way will be to put it in an otherwise
empty JAR at META-INF/geronimo-plugin.xml and then try installing that
JAR using the command-line deploy tool (deployer install-plugin
yourfile.jar).  Let me know how you make out.

Once this is working, we should create plugin metadata files for many
of the CARs on the list, which will let us install the appropriate
settings into config.xml (ports and so on), as well as copying any
needed files into var/* or whatever.  I don't think this is
super-critical (many of the important files and settings will be there
already), but it will be nice to have.

We should also probably create JMS+Derby and EJB+Derby upgrade
packages in case people don't want to do the full Minimal-J2EE
upgrade.

Thanks,
Aaron


Matt Hogstrom wrote:


 Rodent of Unusual Size wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Matt Hogstrom wrote:

 If others feel that it needs to be at Apache *AND* are willing to set
 it up then this is the time to speak up.


 If 'it' is singular, then having 'it' hosted at Apache means
 only Apache-licensed plugins can go into it.  No GPL or
 LGPL or others..

 Based on that I think sticking with 'it' being geronimoplugins.com
 (although .org might be/have been better) makes sense.  When
 the Geronimo project has a significant number -- like, say, a
 dozen or so -- then having an ASF repo for them might be worth
 revisiting.


 I'm of the same mind that we don't have enough content to warrant the
 churn to create the resources at Apache now.

 I think there are lots of good ideas but Aaron did create the code and
 make it work so I'll give him credit for that effort.  The point of this
 thread is to identify people that want to work on the plugin repo at
 Apache and I don't think we've found them yet :)


 For now let's stick with geronimoplugins.com -- but make sure
 the code can handle a *list* of repositories.
 - --
 #kenP-)}

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

 Millennium hand and shrimp!
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.2.4 (MingW32)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

 iQCVAwUBRJKE0ZrNPMCpn3XdAQJnzwP/SaS+1r994T8VJ6VvGD+deCod/GCZs8b5
 +6MfKXvjgPqg6dRPKfvrGn8UblnhT0WL+/0kZH1+230/fWmM5ngMLCIS3c/cxvmP
 8M53v2UD6JPtLfyos6wgOc9bLe5JKGSbqRJms8TAIXBiX+csjC1huHqfitRyvgp/
 DdtgCZFEIzw=
 =01nm
 -END PGP SIGNATURE-

Re: Request change to RTC Process

2006-06-19 Thread Prasad Kashyap


On 6/17/06, Rodent of Unusual Size [EMAIL PROTECTED] wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


I don't consider this valid, either.  If you have the
time to be a committer, you have the time to be part of
the community and collaborate with your peers on the
project.  One thing about RTC is that it tends to promote
interaction, since people are dependent on each other and
the occasional quid pro quo -- unlike the everyone haring
off in his own direction with no-one else watching that
can occur (and has occurred) under CTR.

No-one says you have to test *anyone* else's patches.  Unless,
of course, you hope they'll test *yours*, which is where
the collaboration-for-the-project aspect comes in.  So if
you don't find time to test someone else's code, regardless
of for whom he may work, don't expect him to spend a lot
of time testing *yours*.



True. But this quid pro quo holds good only for code submitted by
committers. Consider the case of active contributors who are
non-committers. If they choose to work on JIRAs in the wish list, it
will be quite a herculean task for them to get a sign-off from 3
committers. The you scratch my back, I'll scratch yours convenience
is not available for non-committers.

Going by this thread, if the committers of the project are
apprehensive about the RTC model and are requesting changes, then
contributors have an even tougher task cut out for them.  I hope that
doesn't sent a message to the community that only patches from
committers have any chance of getting in. I hope that doesn't
de-moralize the non-committers and turn them away from the project.

The RTC is not entirely bad either. It is a good thing to happen to
the project but not in it's present form. What would be good for
Geronimo would be take the best of RTC and CTR.

Here's something to think about -
1) Bug fixes (esp. blockers)  shouldn't need a review.
2) Improvements need atleast ONE +1 vote by a commiter. RTC turns into
CTR after 15 days. A reminder message to be sent 3 days before the
model changes to CTR.
3) Features need THREE +1 votes by other committers. RTC turns into
CTR after 30 days. A reminder message to be sent 7 days before the
model changes to CTR

Just a suggestion.

Cheers
Prasad.



- --
#kenP-|}

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

Millennium hand and shrimp!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRJQ1JZrNPMCpn3XdAQKLAQQAx58qgOEEdnrL79vPuXn8AWYwgrVcwH1j
X7cnZsvTGmQ4uZW7GiCjjkU2E0H0gGMIRUHFCuV8lul85DectAxE3+4M6pYPAG8v
wzg8OOYUl4Wmv6s31M1VDBruCseGLh01c+ilYl2G61mM+c+Ppt3dduD/VCqQDeao
38KzZSDD1WM=
=M+w0
-END PGP SIGNATURE-

[jira] Reopened: (AMQ-732) Infinite recovery loop.

2006-06-19 Thread Hiram Chirino (JIRA)

 [ https://issues.apache.org/activemq/browse/AMQ-732?page=all ]
 
Hiram Chirino reopened AMQ-732:
---


ah.. just noticed that 4.0.1 did not build a new activeio and ship with the new 
version.  I guess this will make it into 4.0.2 then.

 Infinite recovery loop.
 ---

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

   Components: Broker
 Versions: 4.0
  Environment: Linux RHEL 3
 Reporter: Maxim Fateev
 Assignee: Hiram Chirino
  Fix For: 4.1, 4.0.2
  Attachments: activemq-data-1-journal.tar.gz, activemq-data-2-journal.tar.gz


 The simplest way to reproduce the problem:
 1. Remove storage directory. 
 2. Start broker using the following code:
  public static void main(String[] args)  throws Exception {
BrokerService broker = new BrokerService();
broker.setPersistent(true);
DefaultPersistenceAdapterFactory pFactory = new 
 DefaultPersistenceAdapterFactory();
pFactory.setJournalLogFiles(1);
pFactory.setJournalLogFileSize(2048);
broker.setPersistenceFactory(pFactory);
broker.setUseJmx(false);
broker.addConnector(tcp://localhost:61616);
broker.start();
Thread.sleep(1l);
}
 3. Shutdown the broker.
 4. Start broker.
 It enters infinite loop
 [  main] BrokerService  INFO  
 ActiveMQ null JMS Message Broker (localhost) is starting
 [  main] BrokerService  INFO  For 
 help or more information please see: http://incubator.apache.org/activemq/
 [  main] JDBCPersistenceAdapter INFO  
 Database driver recognized: [apache_derby_embedded_jdbc_driver]
 [  main] DefaultJDBCAdapter DEBUG 
 Executing SQL: CREATE TABLE ACTIVEMQ_MSGS(ID INTEGER NOT NULL, CONTAINER 
 VARCHAR(250), MSGID_PROD VARCHAR(250), MSGID_SEQ INTEGER, EXPIRATION BIGINT, 
 MSG BLOB, PRIMARY KEY ( ID ) )
 [  main] DefaultJDBCAdapter DEBUG Could 
 not create JDBC tables; The message table already existed. Failure was: 
 CREATE TABLE ACTIVEMQ_MSGS(ID INTEGER NOT NULL, CONTAINER VARCHAR(250), 
 MSGID_PROD VARCHAR(250), MSGID_SEQ INTEGER, EXPIRATION BIGINT, MSG BLOB, 
 PRIMARY KEY ( ID ) ) Message: Table/View 'ACTIVEMQ_MSGS' already exists in 
 Schema 'APP'. SQLState: X0Y32 Vendor code: 2
 [  main] DefaultJDBCAdapter DEBUG 
 Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_MIDX ON ACTIVEMQ_MSGS 
 (MSGID_PROD,MSGID_SEQ)
 [  main] DefaultJDBCAdapter DEBUG 
 Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_CIDX ON ACTIVEMQ_MSGS (CONTAINER)
 [  main] DefaultJDBCAdapter DEBUG 
 Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_EIDX ON ACTIVEMQ_MSGS (EXPIRATION)
 [  main] DefaultJDBCAdapter DEBUG 
 Executing SQL: CREATE TABLE ACTIVEMQ_ACKS(CONTAINER VARCHAR(250) NOT NULL, 
 CLIENT_ID VARCHAR(250) NOT NULL, SUB_NAME VARCHAR(250) NOT NULL, SELECTOR 
 VARCHAR(250), LAST_ACKED_ID INTEGER, PRIMARY KEY ( CONTAINER, CLIENT_ID, 
 SUB_NAME))
 [  main] DefaultJDBCAdapter DEBUG Could 
 not create JDBC tables; The message table already existed. Failure was: 
 CREATE TABLE ACTIVEMQ_ACKS(CONTAINER VARCHAR(250) NOT NULL, CLIENT_ID 
 VARCHAR(250) NOT NULL, SUB_NAME VARCHAR(250) NOT NULL, SELECTOR VARCHAR(250), 
 LAST_ACKED_ID INTEGER, PRIMARY KEY ( CONTAINER, CLIENT_ID, SUB_NAME)) 
 Message: Table/View 'ACTIVEMQ_ACKS' already exists in Schema 'APP'. SQLState: 
 X0Y32 Vendor code: 2
 [  main] JDBCPersistenceAdapter DEBUG 
 Cleaning up old messages.
 [  main] DefaultJDBCAdapter DEBUG 
 Executing SQL: DELETE FROM ACTIVEMQ_MSGS WHERE ( EXPIRATION0 AND 
 EXPIRATION?) OR ID = ( SELECT min(ACTIVEMQ_ACKS.LAST_ACKED_ID) FROM 
 ACTIVEMQ_ACKS WHERE ACTIVEMQ_ACKS.CONTAINER=ACTIVEMQ_MSGS.CONTAINER)
 [  main] DefaultJDBCAdapter DEBUG Deleted 
 0 old message(s).
 [  main] JDBCPersistenceAdapter DEBUG Cleanup 
 done.
 [  main] JournalPersistenceAdapter  INFO  Journal 
 Recovery Started from: Active Journal: using 1 x 0.001953125 Megs at: 
 /workplace/fateev/install/activemq-4.0-SNAPSHOT/activemq-core/activemq-data/journal
 [  main] JournalPersistenceAdapter  DEBUG TRACE 
 Entry: RECOVERED
 [Journal Writer] LogFileManager DEBUG 
 getNextDataRecordLocation offset=53
 [Journal Writer] LogFileManager DEBUG 
 getNextDataRecordLocation offset=97
 [Journal Writer] LogFileManager DEBUG

[jira] Updated: (AMQ-732) Infinite recovery loop.

2006-06-19 Thread Hiram Chirino (JIRA)

 [ https://issues.apache.org/activemq/browse/AMQ-732?page=all ]

Hiram Chirino updated AMQ-732:
--

Fix Version: 4.0.2
 (was: 4.0.1)

 Infinite recovery loop.
 ---

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

   Components: Broker
 Versions: 4.0
  Environment: Linux RHEL 3
 Reporter: Maxim Fateev
 Assignee: Hiram Chirino
  Fix For: 4.1, 4.0.2
  Attachments: activemq-data-1-journal.tar.gz, activemq-data-2-journal.tar.gz


 The simplest way to reproduce the problem:
 1. Remove storage directory. 
 2. Start broker using the following code:
  public static void main(String[] args)  throws Exception {
BrokerService broker = new BrokerService();
broker.setPersistent(true);
DefaultPersistenceAdapterFactory pFactory = new 
 DefaultPersistenceAdapterFactory();
pFactory.setJournalLogFiles(1);
pFactory.setJournalLogFileSize(2048);
broker.setPersistenceFactory(pFactory);
broker.setUseJmx(false);
broker.addConnector(tcp://localhost:61616);
broker.start();
Thread.sleep(1l);
}
 3. Shutdown the broker.
 4. Start broker.
 It enters infinite loop
 [  main] BrokerService  INFO  
 ActiveMQ null JMS Message Broker (localhost) is starting
 [  main] BrokerService  INFO  For 
 help or more information please see: http://incubator.apache.org/activemq/
 [  main] JDBCPersistenceAdapter INFO  
 Database driver recognized: [apache_derby_embedded_jdbc_driver]
 [  main] DefaultJDBCAdapter DEBUG 
 Executing SQL: CREATE TABLE ACTIVEMQ_MSGS(ID INTEGER NOT NULL, CONTAINER 
 VARCHAR(250), MSGID_PROD VARCHAR(250), MSGID_SEQ INTEGER, EXPIRATION BIGINT, 
 MSG BLOB, PRIMARY KEY ( ID ) )
 [  main] DefaultJDBCAdapter DEBUG Could 
 not create JDBC tables; The message table already existed. Failure was: 
 CREATE TABLE ACTIVEMQ_MSGS(ID INTEGER NOT NULL, CONTAINER VARCHAR(250), 
 MSGID_PROD VARCHAR(250), MSGID_SEQ INTEGER, EXPIRATION BIGINT, MSG BLOB, 
 PRIMARY KEY ( ID ) ) Message: Table/View 'ACTIVEMQ_MSGS' already exists in 
 Schema 'APP'. SQLState: X0Y32 Vendor code: 2
 [  main] DefaultJDBCAdapter DEBUG 
 Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_MIDX ON ACTIVEMQ_MSGS 
 (MSGID_PROD,MSGID_SEQ)
 [  main] DefaultJDBCAdapter DEBUG 
 Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_CIDX ON ACTIVEMQ_MSGS (CONTAINER)
 [  main] DefaultJDBCAdapter DEBUG 
 Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_EIDX ON ACTIVEMQ_MSGS (EXPIRATION)
 [  main] DefaultJDBCAdapter DEBUG 
 Executing SQL: CREATE TABLE ACTIVEMQ_ACKS(CONTAINER VARCHAR(250) NOT NULL, 
 CLIENT_ID VARCHAR(250) NOT NULL, SUB_NAME VARCHAR(250) NOT NULL, SELECTOR 
 VARCHAR(250), LAST_ACKED_ID INTEGER, PRIMARY KEY ( CONTAINER, CLIENT_ID, 
 SUB_NAME))
 [  main] DefaultJDBCAdapter DEBUG Could 
 not create JDBC tables; The message table already existed. Failure was: 
 CREATE TABLE ACTIVEMQ_ACKS(CONTAINER VARCHAR(250) NOT NULL, CLIENT_ID 
 VARCHAR(250) NOT NULL, SUB_NAME VARCHAR(250) NOT NULL, SELECTOR VARCHAR(250), 
 LAST_ACKED_ID INTEGER, PRIMARY KEY ( CONTAINER, CLIENT_ID, SUB_NAME)) 
 Message: Table/View 'ACTIVEMQ_ACKS' already exists in Schema 'APP'. SQLState: 
 X0Y32 Vendor code: 2
 [  main] JDBCPersistenceAdapter DEBUG 
 Cleaning up old messages.
 [  main] DefaultJDBCAdapter DEBUG 
 Executing SQL: DELETE FROM ACTIVEMQ_MSGS WHERE ( EXPIRATION0 AND 
 EXPIRATION?) OR ID = ( SELECT min(ACTIVEMQ_ACKS.LAST_ACKED_ID) FROM 
 ACTIVEMQ_ACKS WHERE ACTIVEMQ_ACKS.CONTAINER=ACTIVEMQ_MSGS.CONTAINER)
 [  main] DefaultJDBCAdapter DEBUG Deleted 
 0 old message(s).
 [  main] JDBCPersistenceAdapter DEBUG Cleanup 
 done.
 [  main] JournalPersistenceAdapter  INFO  Journal 
 Recovery Started from: Active Journal: using 1 x 0.001953125 Megs at: 
 /workplace/fateev/install/activemq-4.0-SNAPSHOT/activemq-core/activemq-data/journal
 [  main] JournalPersistenceAdapter  DEBUG TRACE 
 Entry: RECOVERED
 [Journal Writer] LogFileManager DEBUG 
 getNextDataRecordLocation offset=53
 [Journal Writer] LogFileManager DEBUG 
 getNextDataRecordLocation offset=97
 [Journal Writer] LogFileManager DEBUG 
 getNextDataRecordLocation overflowing into next logFile=0
 [

Fwd: [CONSENSUS] Default plugin site (was Re: Frustrations of a Release Manager)

2006-06-19 Thread Bruce Snyder

Forwarding request to infra@ list.

-- Forwarded message --
From: Paul McMahan [EMAIL PROTECTED]
Date: Jun 19, 2006 8:51 AM
Subject: Re: [CONSENSUS] Default plugin site (was Re: Frustrations of
a Release Manager)
To: dev@geronimo.apache.org

There's an interesting plugin site for eclipse at
eclipseplugincentral.com that implements some of the ideas we have
discussed.  It provides a directory of plugins but not the actual
files themselves, pointing elsewhere for the purchase/download.  It
also provides a rating system, news page, and discussion forums.  IMHO
the geronimo project should strive to provide this type of site for
building a healthy commercial and open source community around
geronimo plugins.

The domain names geronimoplugincentral.com and
geronimoplugincentral.org were available and match the form used by
eclipseplugincentral.com so I purchased them and would like to
donate them to the ASF.  How can I do that?  Just send a note to
[EMAIL PROTECTED]

--
perl -e 'print unpack(u30,D0G)[EMAIL 
PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT*
);'

Apache Geronimo - http://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/

[Fwd: [VOTE] Geronimo 1.1, DayTrader 1.1 and Specs 1.1 Final-2 Vote]

I originally sent this note about 3 hours ago.  Not sure where the bottleneck is so I'm trying 
again.  Apologies if there are duplicates.

 Original Message 
Subject: [VOTE] Geronimo 1.1, DayTrader 1.1 and Specs 1.1 Final-2 Vote
Date: Mon, 19 Jun 2006 11:33:31 -0400
From: Matt Hogstrom [EMAIL PROTECTED]
To: dev@geronimo.apache.org,  [EMAIL PROTECTED],  user@geronimo.apache.org

Here are the latest binaries built from
http://svn.apache.org/repos/asf/geronimo/branches/1.1.0,
http://svn.apache.org/repos/asf/geronimo/specs/tags/1_1 and
http://svn.apache.org/repos/asf/geronimo/daytrader/branches/1.1.0.

I believe this will start a new vote for this binary.  All issues that I'm 
aware of have been
addressed that needed to be for this release.  RELEASE-NOTES-1.1.txt were 
updated with issues that
will be addressed in 1.1.1.

*Previous Votes are invalidated...please re-vote*

The console has been updated to reflect issues related to bad links.

Consensus appears to favor defering the LICENSE issue in the console to 1.1.1 
as the correct LICENSE
and NOTICES files are included in the builds.

DayTrader sources are included with updated README to instruct the user how to 
build and install
DayTrader on Geronimo.

Please cast your votes and remember that only PMC member votes are binding.  
However, I am confident
that commiter votes will help to inform the PMC of the quality of this release 
candidate.

Thanks to all that have been checking this out.  John Sisson especially has 
been burning the
midnight oil and finding the remaining issues that have helped to improve the 
quality of this release.

*Geronimo 1.1 Version*

   *Source*

http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1-final-2_src.tar.gz
 http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1-final-2_src.zip

   *Full J2EE Jetty Version*

http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-j2ee-1.1-final-2.tar.gz

http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-j2ee-1.1-final-2.zip

   *Minimal Jetty Version*

http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-minimal-1.1-final-2.tar.gz

http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-minimal-1.1-final-2.zip

   *Full Tomcat Version*

http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-j2ee-1.1-final-2.tar.gz

http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-j2ee-1.1-final-2.zip

   *Minimal Tomcat Version*

http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-minimal-1.1-final-2.tar.gz

http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-minimal-1.1-final-2.zip

   *Geronimo 1.1 Spec Jars*
 *Source*

http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs_src-1.1-final-2.tar.gz

http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs_src-1.1-final-2.zip
 *Binaries*

http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs-1.1-final-2.tar.gz

http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs-1.1-final-2.zip

*DayTrader 1.1 Version*
  *Source*

http://people.apache.org/~hogstrom/1.1-final2/daytrader_src-1.1-final-2.tar.gz
 http://people.apache.org/~hogstrom/1.1-final2/daytrader_src-1.1-final-2.zip
  *Ear*
 http://people.apache.org/~hogstrom/1.1-final2/daytrader-ear-1.1-final-2.ear
 Note: to build Geronimo the above ear needs to be placed into your repo as
   $MAVEN_HOME/repository/geronimo/ears/daytrader-ear-1.1.ear

Re: Where did the 1.1 branch go?!?! - Summary and recommendation

2006-06-19 Thread toby cabot

Hi,

On Fri, Jun 16, 2006 at 12:40:03AM -0400, Matt Hogstrom wrote:
 Working copies of versions in branches would be branches/n.n.  This would 
 be the effective trunk for any version work.

Does this mean that someone will be re-creating a branches/1.1 branch?
There used to be one, and it looks as if there isn't one now.
Otherwise I can do a new checkout of the 1.1.1 branch but if there's
going to be a 1.1 branch I think I'd rather track it than a specific
release branch.

Thanks,
Toby

Web site update

2006-06-19 Thread Hernan Cunico


Hi All,
I'm a bit lost with the two branches we have now to manage the web site.  I have the 
.../site/branches/may2006 branch updated and ready to go live, it already includes that last two 
changes (updated events and added book to documentation).


What would be the next step? replacing the content of .../site/trunk and then commit to the live 
site from the updated trunk? how do I replace it the content in .../site/trunk with the may2006 branch?


Thanks

Cheers!
Hernan

[jira] Created: (GERONIMO-2138) Configuration jsp-examples-tomcat includes Jetty dependencies

2006-06-19 Thread Donald Woods (JIRA)

Configuration jsp-examples-tomcat includes Jetty dependencies
-

 Key: GERONIMO-2138
 URL: http://issues.apache.org/jira/browse/GERONIMO-2138
 Project: Geronimo
Type: Bug
Security: public (Regular issues) 
  Components: sample apps  
Versions: 1.1
 Environment: Geronimo 1.1.0 RC2
Reporter: Donald Woods
 Assigned to: Donald Woods 
Priority: Trivial
 Fix For: 1.1.1


Will attach a patch to remove the following build dependencies -
  jetty-deployer-1.1.car
  geronimo-jetty-1.1.jar


-- 
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: M2 : Build Instruction

2006-06-19 Thread Jacek Laskowski


On 6/19/06, anita kulshreshtha [EMAIL PROTECTED] wrote:


   I was looking for a suitable place to add the build instrucitons for
M2. I could not find any section dealing with the trunk at
http://cwiki.apache.org/geronimo/


Pick your favorite name and propose it. Send a note to dev and await
comments. Upon having received some, go and create it.

What about 'Apache Geronimo Build using Apache Maven 2' ?


Anita


Jacek

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

Re: Wiki based FAQ

2006-06-19 Thread Jacek Laskowski


On 6/17/06, Dain Sundstrom [EMAIL PROTECTED] wrote:

I put together a FAQ in the sandbox on the cwiki.  I seeded it with
content from the main wiki on the Geronimo website and with some
content from a resent email I sent about accessing an MBean server
from a GBean.

This is just an idea, and I will have no hard feelings if we decide
to delete it (it only took 20 minutes to get going).

http://cwiki.apache.org/confluence/display/GMOxSBOX/FAQ

What do you think?


The more places one can contribute the better. Documentation is always
a big PITA for open source projects so I don't worry about its
existence. It will survive, esp. now when editing is so easy to do.

I wonder why the name is so...well...different? How was it chosen?

+1


-dain


Jacek

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

[jira] Created: (AMQ-761) ActiveMQConnectionFactory.setBrokerURL does not set all connection properties corrrectly

2006-06-19 Thread Jim Beattie (JIRA)

ActiveMQConnectionFactory.setBrokerURL does not set all connection properties 
corrrectly


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

  Components: JMS client  
Versions: 3.2.2
 Environment: Windows XP, Java 1.4.1
Reporter: Jim Beattie
 Attachments: UrlSetterTest.java

If I set the brokerUrl of ActiveMQConnectionFactory using setBrokerURL(), the 
connection factory does not reparse all of the properties from the URL.  As a 
result, when a new connection is created, some of the properties from the URL 
specified during the construction of the connection factory (typically the 
defaults) are used instead.  Attached is a unit test to demonstrate the problem.

As a minimum, the following block of code is required in setBrokerURL().  But 
this doesn't really fix it because properties settings from the URL used by the 
constructor may not be reset by this code.  A structural change may be in order 
(e.g. just-in-time parsing of the properties).

   if( brokerURL.indexOf(?)= 0 ) {
String options = brokerURL.substring(brokerURL.indexOf(?)+1);
Map properties = URIHelper.parseQuery(options);
if (!properties.isEmpty()) {
BeanUtils.populate(this, properties);
}   

-- 
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: [Fwd: [VOTE] Geronimo 1.1, DayTrader 1.1 and Specs 1.1 Final-2 Vote]

2006-06-19 Thread Davanum Srinivas


+1 from me.

Thanks,
dims

PS: Please don't cc a closed list.

On 6/19/06, Matt Hogstrom [EMAIL PROTECTED] wrote:

I originally sent this note about 3 hours ago.  Not sure where the bottleneck 
is so I'm trying
again.  Apologies if there are duplicates.

 Original Message 
Subject: [VOTE] Geronimo 1.1, DayTrader 1.1 and Specs 1.1 Final-2 Vote
Date: Mon, 19 Jun 2006 11:33:31 -0400
From: Matt Hogstrom [EMAIL PROTECTED]
To: dev@geronimo.apache.org,  [EMAIL PROTECTED],  user@geronimo.apache.org

Here are the latest binaries built from
http://svn.apache.org/repos/asf/geronimo/branches/1.1.0,
http://svn.apache.org/repos/asf/geronimo/specs/tags/1_1 and
http://svn.apache.org/repos/asf/geronimo/daytrader/branches/1.1.0.

I believe this will start a new vote for this binary.  All issues that I'm 
aware of have been
addressed that needed to be for this release.  RELEASE-NOTES-1.1.txt were 
updated with issues that
will be addressed in 1.1.1.

*Previous Votes are invalidated...please re-vote*

The console has been updated to reflect issues related to bad links.

Consensus appears to favor defering the LICENSE issue in the console to 1.1.1 
as the correct LICENSE
and NOTICES files are included in the builds.

DayTrader sources are included with updated README to instruct the user how to 
build and install
DayTrader on Geronimo.

Please cast your votes and remember that only PMC member votes are binding.  
However, I am confident
that commiter votes will help to inform the PMC of the quality of this release 
candidate.

Thanks to all that have been checking this out.  John Sisson especially has 
been burning the
midnight oil and finding the remaining issues that have helped to improve the 
quality of this release.

*Geronimo 1.1 Version*

*Source*
  
http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1-final-2_src.tar.gz
  http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1-final-2_src.zip

*Full J2EE Jetty Version*
  
http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-j2ee-1.1-final-2.tar.gz
  
http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-j2ee-1.1-final-2.zip

*Minimal Jetty Version*
  
http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-minimal-1.1-final-2.tar.gz
  
http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-minimal-1.1-final-2.zip

*Full Tomcat Version*
  
http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-j2ee-1.1-final-2.tar.gz
  
http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-j2ee-1.1-final-2.zip

*Minimal Tomcat Version*
  
http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-minimal-1.1-final-2.tar.gz
  
http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-minimal-1.1-final-2.zip

*Geronimo 1.1 Spec Jars*
  *Source*
   
http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs_src-1.1-final-2.tar.gz
   
http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs_src-1.1-final-2.zip
  *Binaries*
   
http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs-1.1-final-2.tar.gz
   
http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs-1.1-final-2.zip

*DayTrader 1.1 Version*
   *Source*
  
http://people.apache.org/~hogstrom/1.1-final2/daytrader_src-1.1-final-2.tar.gz
  
http://people.apache.org/~hogstrom/1.1-final2/daytrader_src-1.1-final-2.zip
   *Ear*
  
http://people.apache.org/~hogstrom/1.1-final2/daytrader-ear-1.1-final-2.ear
  Note: to build Geronimo the above ear needs to be placed into your repo as
$MAVEN_HOME/repository/geronimo/ears/daytrader-ear-1.1.ear





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

[jira] Commented: (AMQ-721) Openwire client hangs after receiving 999 messages

2006-06-19 Thread James Stanton (JIRA)

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

James Stanton commented on AMQ-721:
---

I also had the same problem, but I was able to put together a hack that gets 
around this problem.  I don't recommend this as the solution going forward, but 
it appears to work on my test cases (which failed before I implemented it).  

First we need to change the dotNet dll client classes.
in class IMessageConsumer, add a new function:

IMessage AutoAcknowledge(IMessage message);

in class MessageConsumer, make AutoAcknowledge public rather then protected.

Then, create your dll.

Now, in your test app do the following:

Let's assume you've created a consumer called consumer and have defined the 
following:
consumer.Listener += new MessageListener(onMessage);

set up the listener function as follows:
public void onMessage(IMessage message)
{
 If (consumer != null) //just a good idea to check
 consumer.AutoAcknowledge(message);
 // whatever you want to do with your message goes here... I've just put a 
Console.WriteLine here, but do whatever you want here
Console.WriteLine(got Message:   + ((ActiveMQTextMessage)message).Text);
}

This isn't an ideal solution, because it requires the MessageListener to call 
AutoAcknowledge, but it seems to work.  I hope this helps folks who are trying 
to do this!

Jamie

 Openwire client hangs after receiving 999 messages
 --

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

   Components: JMS client
 Versions: 4.0
  Environment: .NET 2.0 ,C# + trunk
 Reporter: vincent boilay
 Priority: Blocker



 Openwire client hangs after receiving 999 messages
 changing Session.Prefetch postpone the  problem...
 Current code is :
public class Session : ISession
 {
:
:
 private int prefetchSize = 1000;
 this block at message #999
 changing private int prefetchSize = 2000 ==  blocks at message #1999

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

[jira] Commented: (AMQ-721) Openwire client hangs after receiving 999 messages

2006-06-19 Thread James Stanton (JIRA)

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

James Stanton commented on AMQ-721:
---

Oh, sorry, one more thing.  Make sure you're connecting with 
tcp://localhost:61616?jms.optimizeAcknowledge=false  (the 
jms.optimizeAcknowledge=false being the important part of that, at least until 
4.0.1 is out which defaults to this)

 Openwire client hangs after receiving 999 messages
 --

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

   Components: JMS client
 Versions: 4.0
  Environment: .NET 2.0 ,C# + trunk
 Reporter: vincent boilay
 Priority: Blocker



 Openwire client hangs after receiving 999 messages
 changing Session.Prefetch postpone the  problem...
 Current code is :
public class Session : ISession
 {
:
:
 private int prefetchSize = 1000;
 this block at message #999
 changing private int prefetchSize = 2000 ==  blocks at message #1999

-- 
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: Wiki based FAQ

2006-06-19 Thread Hernan Cunico




Jacek Laskowski wrote:

On 6/17/06, Dain Sundstrom [EMAIL PROTECTED] wrote:


I put together a FAQ in the sandbox on the cwiki.  I seeded it with
content from the main wiki on the Geronimo website and with some
content from a resent email I sent about accessing an MBean server
from a GBean.

This is just an idea, and I will have no hard feelings if we decide
to delete it (it only took 20 minutes to get going).

http://cwiki.apache.org/confluence/display/GMOxSBOX/FAQ

What do you think?



The more places one can contribute the better. Documentation is always
a big PITA for open source projects so I don't worry about its
existence. It will survive, esp. now when editing is so easy to do.

I wonder why the name is so...well...different? How was it chosen?


cwiki.apache.org was decided with the infraestructure folks.

Dain included the direct link to confluence but we now have an customized HTML version that gets 
updated automatically everytime a page is edited. So, to access the wiki you should just typen 
cwiki.apache.org/geronimo


Does that answer your question about the name?

Cheers!
Hernan


+1


-dain



Jacek

Re: Where did the 1.1 branch go?!?! - Summary and recommendation


Done.

On Jun 19, 2006, at 11:36 AM, toby cabot wrote:


Hi,

On Fri, Jun 16, 2006 at 12:40:03AM -0400, Matt Hogstrom wrote:
Working copies of versions in branches would be branches/n.n.   
This would

be the effective trunk for any version work.


Does this mean that someone will be re-creating a branches/1.1 branch?
There used to be one, and it looks as if there isn't one now.
Otherwise I can do a new checkout of the 1.1.1 branch but if there's
going to be a 1.1 branch I think I'd rather track it than a specific
release branch.

Thanks,
Toby

Re: Where did the 1.1 branch go?!?! - Summary and recommendation

2006-06-19 Thread toby cabot

Hi David,

 Done.

Thanks!

Toby

Re: Wiki based FAQ

2006-06-19 Thread Dain Sundstrom


On Jun 19, 2006, at 2:27 PM, Hernan Cunico wrote:


Jacek Laskowski wrote:

On 6/17/06, Dain Sundstrom [EMAIL PROTECTED] wrote:

I put together a FAQ in the sandbox on the cwiki.  I seeded it with
content from the main wiki on the Geronimo website and with some
content from a resent email I sent about accessing an MBean server
from a GBean.

This is just an idea, and I will have no hard feelings if we decide
to delete it (it only took 20 minutes to get going).

http://cwiki.apache.org/confluence/display/GMOxSBOX/FAQ

What do you think?
The more places one can contribute the better. Documentation is  
always

a big PITA for open source projects so I don't worry about its
existence. It will survive, esp. now when editing is so easy to do.
I wonder why the name is so...well...different? How was it chosen?


cwiki.apache.org was decided with the infraestructure folks.

Dain included the direct link to confluence but we now have an  
customized HTML version that gets updated automatically everytime a  
page is edited. So, to access the wiki you should just typen  
cwiki.apache.org/geronimo


Duh :)  I forgot about the exporting.

You can find the page directly here:

http://cwiki.apache.org/GMOxSBOX/faq.html

-dain

Ported gbuild space to cwiki


Hey all,

I ported the GBuild space over to cwiki and updated it slightly.

http://cwiki.apache.org/gbuild/

Next, I'd like to get a Subprojects box in addition to our tab that  
lists GBuild and links directly to the site above.


Love that Geronimo template in cwiki!

-David

Re: Web site update


On Jun 19, 2006, at 12:11 PM, Hernan Cunico wrote:


Hi All,
I'm a bit lost with the two branches we have now to manage the web  
site.  I have the .../site/branches/may2006 branch updated and  
ready to go live, it already includes that last two changes  
(updated events and added book to documentation).


What would be the next step? replacing the content of .../site/ 
trunk and then commit to the live site from the updated trunk? how  
do I replace it the content in .../site/trunk with the may2006 branch?


Typically, you'd merge over your changes.  Could use the 'svn merge'  
command.  Or you could create a patch file and apply it to trunk.  I  
like to use the graphical diff tool in Visual SlickEdit, but that's  
not free.


-David

Re: Request change to RTC Process

I'm not sure Ken's intent was to introduce a new concept as much as he was pointing out a side
benefit. My understanding was that RTC was enforce to improve community collaboration and
communication. Clearly its not working very well based on the comments in this thread. Seems to be
going the opposite way.

Clearly the opinion of some on the thread is they trust each other and communication has already
been fine so this is just slowing them down? Is that the summary? I'd have to disagree that things
have been fine although I'll concede that perhaps some changes to RTC may be warranted.

I'm sitting in an airport right now so I don't have time to do this but it might be nice if someone
can compile some statistics on what has actually transpired and then we can discuss why this isn't
working and then make some recommendations as to how to move forward rather than the current
dialogue which doesn't seem to be improving collaboration and communication but is actually driving
polarization (which I think we're trying to avoid).

Hiram Chirino wrote:

On 6/17/06, Rodent of Unusual Size [EMAIL PROTECTED] wrote:

RTC means tested quality, not assumed quality. If you
can't find people to test the quality of something, it
doesn't go in because the quality isn't assured.

I'm not sure where 'quality' requirement is coming from. I don't
think it's ever been discussed on the list. For example, I don't
remember a discussion of should we focus on stabilizing and in effect
slowing down the development of Geronimo. Or should it focus on
implementing the J2EE features that it's missing as quickly as
possible? I can see how IBM would prefer the 1st option since it
would allow it's chimerical offerings to stay differentiated from
Geronimo. But I don't think the rest of this community would agree.

I'm having trouble understanding the above paragraph and Dain's comments in another e-mail. I
proposed that we take 1.1.1 to stabilize it because there are a number of quality issues in Geronimo
that make it undesireable in a production enviroment. NPEs abound and we have usability problems.
Personally I think these need to be addressed to improve the adoption rate of Geronimo. I'm not
aware of a lot of developers or administrators that accept a server that is 90% reliable (my made up
number). If you disagree that fixing these are a waste of time then please speak up. I have other
things to do then.

I'm also having difficulty understanding the chimerical comment. I can only assume that you mean
that WAS CE is some mythical and unachievable goal? Here is where I'm drawing my inference from:

http://dictionary.reference.com/wordoftheday/archive/2003/02/24.html

Here is a quote from the above:

1. Merely imaginary; produced by or as if by a wildly fanciful imagination; fantastic; improbable or
unrealistic.

If WAS CE is mythical then I'm not sure what hope there is for Geronimo because it is the basis for
WAS CE. If CE can't succeed then I'd say Geronimo poisoned the apple.

Can you please clarify your comments Hiram because they aren't making sense to me. I'm sure you
don't mean the above.

- Eliminates trust. I know say, David J has a lot of experience with
say, connectors, and if he puts a patch in that area, I think I can
read his summary and trust that he's implemented it sensibly. But now
that doesn't count, I have to review it line by line? I think it
should be up to me which patches I trust and which patches want to
review in detail.

Considering the problems concerning trust that are already
extant, I think the first sentence as a conclusion is bogus.
And once again you want to *assume* quality rather than *assure*
it. That's how CTR works. RTC works to *assure* it.

I trust a bunch of the folks that work here and while I could review
patches, unless you are working with that code ALL the time, there
could be unexpected side-effects that only folks working on it all the
time could catch. So I would rather than assume I know what I'm
doing, I'd delegate to folks who specialize in that area of Geronimo.

By way of example, if its connector or Tx code I'd trust Jencks. Perhaps the problem is that
Geronimo has not attracted enough people to have more than one person interested in a specific area.
I would say this is unfortunate but I agree with your trust comment in light of individual components.

- Favors full-time open source developers over free-time
contributors. I don't have enough time to work on the work *I* want
to do in my spare time, much less get a clean tree to apply, test, and
review everyone else's patches

I don't consider this valid, either. If you have the
time to be a committer, you have the time to be part of
the community and collaborate with your peers on the
project. One thing about RTC is that it tends to promote
interaction, since people are dependent on each other and
the occasional quid pro quo -- unlike the everyone

Re: Request change to RTC Process


On Jun 19, 2006, at 4:28 PM, Matt Hogstrom wrote:

I'm not sure Ken's intent was to introduce a new concept as much as  
he was pointing out a side benefit.  My understanding was that RTC  
was enforce to improve community collaboration and communication.   
Clearly its not working very well based on the comments in this  
thread.  Seems to be going the opposite way.


I'd agree with your first two statements, but I think you went a  
little off track in your generalization that it's not working very  
well and seems to be going the opposite way.


I certainly don't agree.  I'm very happy to see so many people say  
they like RTC -- I like it too -- and am encouraged to see people  
actually think about RTC in general and how it can benefit Geronimo  
best.


In the eye of this beholder, these are good omens.

-David

Re: Where did the 1.1 branch go?!?! - Summary and recommendation


Oh, I see. There is already a 1.1.1 branch.  My bad.

Sorry, going to delete the branches/1.1 and call for a vote.

-David

On Jun 19, 2006, at 2:54 PM, toby cabot wrote:


Hi David,


Done.


Thanks!

Toby

Re: Request change to RTC Process

2006-06-19 Thread Hiram Chirino


On 6/19/06, Matt Hogstrom [EMAIL PROTECTED] wrote:

I'm not sure Ken's intent was to introduce a new concept as much as he was 
pointing out a side
benefit.  My understanding was that RTC was enforce to improve community 
collaboration and
communication.  Clearly its not working very well based on the comments in this 
thread.  Seems to be
going the opposite way.

Clearly the opinion of some on the thread is they trust each other and 
communication has already
been fine so this is just slowing them down?  Is that the summary?  I'd have to 
disagree that things
have been fine although I'll concede that perhaps some changes to RTC may be 
warranted.

I'm sitting in an airport right now so I don't have time to do this but it 
might be nice if someone
can compile some statistics on what has actually transpired and then we can 
discuss why this isn't
working and then make some recommendations as to how to move forward rather 
than the current
dialogue which doesn't seem to be improving collaboration and communication but 
is actually driving
polarization (which I think we're trying to avoid).

Hiram Chirino wrote:
 On 6/17/06, Rodent of Unusual Size [EMAIL PROTECTED] wrote:

 RTC means tested quality, not assumed quality.  If you
 can't find people to test the quality of something, it
 doesn't go in because the quality isn't assured.


 I'm not sure where 'quality' requirement is coming from.  I don't
 think it's ever been discussed on the list.  For example, I don't
 remember a discussion of should we focus on stabilizing and in effect
 slowing down the development of Geronimo.  Or should it focus on
 implementing the J2EE features that it's missing as quickly as
 possible?  I can see how IBM would prefer the 1st option since it
 would allow it's chimerical offerings to stay differentiated from
 Geronimo. But I don't think the rest of this community would agree.

I'm having trouble understanding the above paragraph and Dain's comments in 
another e-mail.  I
proposed that we take 1.1.1 to stabilize it because there are a number of 
quality issues in Geronimo
that make it undesireable in a production enviroment.  NPEs abound and we have 
usability problems.
Personally I think these need to be addressed to improve the adoption rate of 
Geronimo.  I'm not
aware of a lot of developers or administrators that accept a server that is 90% 
reliable (my made up
number).  If you disagree that fixing these are a waste of time then please 
speak up.  I have other
things to do then.


I think that's great! and I hope a 1.1.2 rolls out soon too and that
the 1.1 branch keeps stabilizing at a good pace.



I'm also having difficulty understanding the chimerical comment.  I can only 
assume that you mean
that WAS CE is some mythical and unachievable goal?  Here is where I'm drawing 
my inference from:

http://dictionary.reference.com/wordoftheday/archive/2003/02/24.html

Here is a quote from the above:

1. Merely imaginary; produced by or as if by a wildly fanciful imagination; 
fantastic; improbable or
unrealistic.

If WAS CE is mythical then I'm not sure what hope there is for Geronimo because 
it is the basis for
WAS CE.  If CE can't succeed then I'd say Geronimo poisoned the apple.

Can you please clarify your comments Hiram because they aren't making sense to 
me.  I'm sure you
don't mean the above.



lol.. that's why you can't trust spell checkers! replace chimerical
with commercial!  I was more referring to WAS compared to WASCE and it
staying highly differentiated because RTC could stifle geronimo's
innovation.




   - Eliminates trust.  I know say, David J has a lot of experience with
  say, connectors, and if he puts a patch in that area, I think I can
  read his summary and trust that he's implemented it sensibly.  But now
  that doesn't count, I have to review it line by line?  I think it
  should be up to me which patches I trust and which patches want to
  review in detail.

 Considering the problems concerning trust that are already
 extant, I think the first sentence as a conclusion is bogus.
 And once again you want to *assume* quality rather than *assure*
 it.  That's how CTR works.  RTC works to *assure* it.


 I trust a bunch of the folks that work here and while I could review
 patches, unless you are working with that code ALL the time, there
 could be unexpected side-effects that only folks working on it all the
 time could catch.  So I would rather than assume I know what I'm
 doing, I'd delegate to folks who specialize in that area of Geronimo.


By way of example, if its connector or Tx code I'd trust Jencks.  Perhaps the 
problem is that
Geronimo has not attracted enough people to have more than one person 
interested in a specific area.
  I would say this is unfortunate but I agree with your trust comment in light 
of individual components.

   - Favors full-time open source developers over free-time
  contributors.  I don't have enough time to work on the work *I* want
  to do in my spare time,

Re: Request change to RTC Process

2006-06-19 Thread Hiram Chirino


On 6/19/06, Dain Sundstrom [EMAIL PROTECTED] wrote:

On Jun 19, 2006, at 4:28 PM, Matt Hogstrom wrote:

 Clearly the opinion of some on the thread is they trust each other
 and communication has already been fine so this is just slowing
 them down?  Is that the summary?  I'd have to disagree that things
 have been fine although I'll concede that perhaps some changes to
 RTC may be warranted.

I think that the model of reviewing is working and I like it.  What I
don't like is the requirement to physically apply every patch and run
a full build.  I feel that a careful read of the patch is good enough
for trunk and tends to spur collaboration and communication that was
the original intent of switching to RTC.



+1


For micro releases, I taking a more conservative approach may be
warranted, but I honestly don't see how applying a patch and building
it is going to find more error.  For example, the NPEs you pointed
out are likely to only be found by testing user applications, and
when we do find one a test case should be added to prevent regressions.

-dain





--
Regards,
Hiram

Blog: http://hiramchirino.com

[VOTE] Geronimo 1.1, DayTrader 1.1 and Specs 1.1 Final-2 Vote


Here are the latest binaries built from
http://svn.apache.org/repos/asf/geronimo/branches/1.1.0,
http://svn.apache.org/repos/asf/geronimo/specs/tags/1_1 and
http://svn.apache.org/repos/asf/geronimo/daytrader/branches/1.1.0.

I believe this will start a new vote for this binary.  All issues that I'm aware of have been 
addressed that needed to be for this release.  RELEASE-NOTES-1.1.txt were updated with issues that 
will be addressed in 1.1.1.


*Previous Votes are invalidated...please re-vote*

The console has been updated to reflect issues related to bad links.

Consensus appears to favor defering the LICENSE issue in the console to 1.1.1 as the correct LICENSE 
and NOTICES files are included in the builds.


DayTrader sources are included with updated README to instruct the user how to build and install 
DayTrader on Geronimo.


Please cast your votes and remember that only PMC member votes are binding.  However, I am confident 
that commiter votes will help to inform the PMC of the quality of this release candidate.


Thanks to all that have been checking this out.  John Sisson especially has been burning the 
midnight oil and finding the remaining issues that have helped to improve the quality of this release.


*Geronimo 1.1 Version*

   *Source*
 
http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1-final-2_src.tar.gz
 http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1-final-2_src.zip

   *Full J2EE Jetty Version*
 
http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-j2ee-1.1-final-2.tar.gz
 
http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-j2ee-1.1-final-2.zip

   *Minimal Jetty Version*
 
http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-minimal-1.1-final-2.tar.gz
 
http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-minimal-1.1-final-2.zip

   *Full Tomcat Version*
 
http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-j2ee-1.1-final-2.tar.gz
 
http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-j2ee-1.1-final-2.zip

   *Minimal Tomcat Version*
 
http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-minimal-1.1-final-2.tar.gz
 
http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-minimal-1.1-final-2.zip

   *Geronimo 1.1 Spec Jars*
 *Source*
  
http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs_src-1.1-final-2.tar.gz
  
http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs_src-1.1-final-2.zip
 *Binaries*
  
http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs-1.1-final-2.tar.gz
  
http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs-1.1-final-2.zip

*DayTrader 1.1 Version*
  *Source*
 
http://people.apache.org/~hogstrom/1.1-final2/daytrader_src-1.1-final-2.tar.gz
 http://people.apache.org/~hogstrom/1.1-final2/daytrader_src-1.1-final-2.zip
  *Ear*
 http://people.apache.org/~hogstrom/1.1-final2/daytrader-ear-1.1-final-2.ear
 Note: to build Geronimo the above ear needs to be placed into your repo as
   $MAVEN_HOME/repository/geronimo/ears/daytrader-ear-1.1.ear

Re: Wiki based FAQ

2006-06-19 Thread Jason Dillon


+1

I think that this is a good idea.  I setup a wiki-based Knowledge  
Base at my previous company in Confluence and it really helped to  
collect and spread knowledge.


For this to work in Confluence it should have its own space, like  
GMOxKB.  It also works really well when using the {excerpt}  macro to  
give the TOC more context, and the {scrollbar} macro to make it  
easier to navigate through pages in the KB.


--jason


On Jun 16, 2006, at 3:19 PM, Dain Sundstrom wrote:

I put together a FAQ in the sandbox on the cwiki.  I seeded it with  
content from the main wiki on the Geronimo website and with some  
content from a resent email I sent about accessing an MBean server  
from a GBean.


This is just an idea, and I will have no hard feelings if we decide  
to delete it (it only took 20 minutes to get going).


http://cwiki.apache.org/confluence/display/GMOxSBOX/FAQ

What do you think?

-dain

Re: [VOTE] Geronimo 1.1, DayTrader 1.1 and Specs 1.1 Final-2 Vote