[jira] Created: (AMQ-983) Inactivity Monitor causes a InterruptedException in broker when connection is disconnected

2006-10-17 Thread Jonas Lim (JIRA)
 Inactivity Monitor causes a InterruptedException in broker when connection is 
disconnected
---

 Key: AMQ-983
 URL: https://issues.apache.org/activemq/browse/AMQ-983
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 4.0.1
Reporter: Jonas Lim
 Assigned To: Jonas Lim
 Fix For: 4.0.3, 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] Resolved: (AMQ-983) Inactivity Monitor causes a InterruptedException in broker when connection is disconnected

2006-10-17 Thread Jonas Lim (JIRA)
 [ https://issues.apache.org/activemq/browse/AMQ-983?page=all ]

Jonas Lim resolved AMQ-983.
---

Resolution: Fixed

fix at :

trunk :  rev 464880

4.0 branch : rev 464881

  Inactivity Monitor causes a InterruptedException in broker when connection 
 is disconnected
 ---

 Key: AMQ-983
 URL: https://issues.apache.org/activemq/browse/AMQ-983
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 4.0.1
Reporter: Jonas Lim
 Assigned To: Jonas Lim
 Fix For: 4.0.3, 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-974) .Net client needs centralised trace facility

2006-10-17 Thread Rob Lugt (JIRA)
[ 
https://issues.apache.org/activemq/browse/AMQ-974?page=comments#action_37214 ] 

Rob Lugt commented on AMQ-974:
--

I found an error in OnException in Connection.cs.  This should be:-

protected void OnException(ITransport sender, Exception 
exception)
{
Tracer.ErrorFormat(Transport Exception: {0}, 
exception.ToString());
}


 .Net client needs centralised trace facility
 

 Key: AMQ-974
 URL: https://issues.apache.org/activemq/browse/AMQ-974
 Project: ActiveMQ
  Issue Type: New Feature
  Components: NMS (C# client)
Affects Versions: 4.0.2
 Environment: Windows
Reporter: Rob Lugt
 Assigned To: james strachan
 Fix For: 4.1

 Attachments: amq974-patch.txt, ITrace.cs, Tracer.cs


 There are several classes within activemq-dotnet which need to write 
 log/trace information.  This data is currently written to an ad-hoc mixture 
 of the Console and System.Diagnostics.Trace.
 Neither of these detinations are suitable because System.Diagnostics.Trace is 
 not fully supported in the .Net compact framework and the Console is 
 unsuitable for severl reasons - not least of which is that output is 
 discarded in a Windows (i.e. non-console) application.
 There are two possible solutions to this problem
 1) adopt log4net as the strategic logging/tracing platform
 2) write our own Tracing interface which can be controlled at run-time to 
 make use of any logging mechanism.
 Log4net is an attractive proposition because it is powerful, full-featured, 
 reliable and is also an Apache incubator project.  However, there is a strong 
 desire to keep activemq-dotnet as clear as possible from any external 
 dependencies.  So far this has been successfull and as there is an 
 alternative solution perhaps we should not create a dependency now.
 Creating a custom Tracing interface is attractive because it is stand-alone 
 and allows the client application to plug-in whichever trace mechanism it 
 requires.  There don't seem to be many down sides to this solution, so I'll 
 post a sample impementation shortly.

-- 
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] Reopened: (AMQ-974) .Net client needs centralised trace facility

2006-10-17 Thread Rob Lugt (JIRA)
 [ https://issues.apache.org/activemq/browse/AMQ-974?page=all ]

Rob Lugt reopened AMQ-974:
--

 
small modification required to Connection.cs

protected void OnException(ITransport sender, Exception 
exception)
{
Tracer.ErrorFormat(Transport Exception: {0}, 
exception.ToString());
}

 .Net client needs centralised trace facility
 

 Key: AMQ-974
 URL: https://issues.apache.org/activemq/browse/AMQ-974
 Project: ActiveMQ
  Issue Type: New Feature
  Components: NMS (C# client)
Affects Versions: 4.0.2
 Environment: Windows
Reporter: Rob Lugt
 Assigned To: james strachan
 Fix For: 4.1

 Attachments: amq974-patch.txt, ITrace.cs, Tracer.cs


 There are several classes within activemq-dotnet which need to write 
 log/trace information.  This data is currently written to an ad-hoc mixture 
 of the Console and System.Diagnostics.Trace.
 Neither of these detinations are suitable because System.Diagnostics.Trace is 
 not fully supported in the .Net compact framework and the Console is 
 unsuitable for severl reasons - not least of which is that output is 
 discarded in a Windows (i.e. non-console) application.
 There are two possible solutions to this problem
 1) adopt log4net as the strategic logging/tracing platform
 2) write our own Tracing interface which can be controlled at run-time to 
 make use of any logging mechanism.
 Log4net is an attractive proposition because it is powerful, full-featured, 
 reliable and is also an Apache incubator project.  However, there is a strong 
 desire to keep activemq-dotnet as clear as possible from any external 
 dependencies.  So far this has been successfull and as there is an 
 alternative solution perhaps we should not create a dependency now.
 Creating a custom Tracing interface is attractive because it is stand-alone 
 and allows the client application to plug-in whichever trace mechanism it 
 requires.  There don't seem to be many down sides to this solution, so I'll 
 post a sample impementation shortly.

-- 
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] Updated: (SM-702) Components instantiated multiple times

2006-10-17 Thread Guillaume Nodet (JIRA)
 [ https://issues.apache.org/activemq/browse/SM-702?page=all ]

Guillaume Nodet updated SM-702:
---

Fix Version/s: 3.0.1
   3.1

 Components instantiated multiple times
 --

 Key: SM-702
 URL: https://issues.apache.org/activemq/browse/SM-702
 Project: ServiceMix
  Issue Type: Improvement
Affects Versions: 3.0
 Environment: Win32 - ServiceMix 3.0-incubating
Reporter: Andrew Chullikal
 Fix For: 3.0.1, 3.1

 Attachments: src.zip


 I've been trying to write some of my own components, taking the file poller 
 example as a starting basis.
 Being a newbie, I just ran the test code through my IDE's debugger and 
 noticed that the components' constructors were being called twice.
 Also, another time consuming exercise was figuring that the endpoint had to 
 be activated in my code, unlike the code present in the servicemix-component 
 package. According to Sun's doc, the component is normaly meant to inform the 
 engine that it has an active endpoint. What worries me here, is that there 
 could be non-portability across containers. Perhaps the code in the 
 PojoSupport init method could log a warning if the is no activated endpoint ?
 Finaly, there seems to be a discrepency between LifeCycleMBean.STARTED in the 
 servicemix-jbi.jar and the javax.jbi.management.LifeCycleMbean.RUNNING token. 
 Otherwise, keep up the good work ...


-- 
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] Updated: (SM-707) Subscription Manager and Flow MBeans do not get unregistered.

2006-10-17 Thread Guillaume Nodet (JIRA)
 [ https://issues.apache.org/activemq/browse/SM-707?page=all ]

Guillaume Nodet updated SM-707:
---

Fix Version/s: 3.0.1
   3.1

 Subscription Manager and Flow MBeans do not get unregistered.
 -

 Key: SM-707
 URL: https://issues.apache.org/activemq/browse/SM-707
 Project: ServiceMix
  Issue Type: Bug
Affects Versions: 3.0
Reporter: Pawel Lipka
Priority: Minor
 Fix For: 3.0.1, 3.1

   Original Estimate: 1 hour
  Remaining Estimate: 1 hour

 These MBeans do not get unregistered upon container shutdown.

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




[jira] Created: (SM-709) Upgrade to xbean 2.7 and Spring 2.0

2006-10-17 Thread Guillaume Nodet (JIRA)
Upgrade to xbean 2.7 and Spring 2.0
---

 Key: SM-709
 URL: https://issues.apache.org/activemq/browse/SM-709
 Project: ServiceMix
  Issue Type: Improvement
Affects Versions: 3.0
Reporter: Guillaume Nodet
 Fix For: 3.0.1, 3.1




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




[jira] Created: (SM-710) Upgrade to jetty 6.0.1

2006-10-17 Thread Guillaume Nodet (JIRA)
Upgrade to jetty 6.0.1
--

 Key: SM-710
 URL: https://issues.apache.org/activemq/browse/SM-710
 Project: ServiceMix
  Issue Type: Improvement
Reporter: Guillaume Nodet
 Fix For: 3.0.1, 3.1




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




[jira] Created: (SM-712) Upgrade to xfire 1.2.2

2006-10-17 Thread Guillaume Nodet (JIRA)
Upgrade to xfire 1.2.2
--

 Key: SM-712
 URL: https://issues.apache.org/activemq/browse/SM-712
 Project: ServiceMix
  Issue Type: Improvement
Reporter: Guillaume Nodet
 Fix For: 3.0.1, 3.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: (SM-709) Upgrade to xbean 2.7 and Spring 2.0

2006-10-17 Thread Guillaume Nodet (JIRA)
[ 
https://issues.apache.org/activemq/browse/SM-709?page=comments#action_37204 ] 

Guillaume Nodet commented on SM-709:


Need to upgrade to xbean 2.7 final when out

 Upgrade to xbean 2.7 and Spring 2.0
 ---

 Key: SM-709
 URL: https://issues.apache.org/activemq/browse/SM-709
 Project: ServiceMix
  Issue Type: Improvement
Affects Versions: 3.0
Reporter: Guillaume Nodet
 Assigned To: Guillaume Nodet
 Fix For: 3.0.1, 3.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: (SM-410) Component Uninstallation : ClassLoader not removed from JVM

2006-10-17 Thread Philippe Pinheiro (JIRA)
[ 
https://issues.apache.org/activemq/browse/SM-410?page=comments#action_37205 ] 

Philippe Pinheiro commented on SM-410:
--

I confirm that this problem still exist on the version 3.0
I also want to add that the number of classloader 
(org.apache.xbean.classloader.JarFileClassLoader)
increases in the JVM after install / uninstall of the same component meaning
that this issue is the cause of a memory leak.

 Component Uninstallation : ClassLoader not removed from JVM
 ---

 Key: SM-410
 URL: https://issues.apache.org/activemq/browse/SM-410
 Project: ServiceMix
  Issue Type: Bug
  Components: servicemix-components
Affects Versions: 3.0-M1
Reporter: Philippe Pinheiro
 Attachments: servicemix.log


 After component uninstallation, the corresponding component classloader is 
 not  removed from the JVM and the jars in the wdir are locked.
 To reproduce this bug you just need to :
 - install the component : servicemix-jms by putting the jar on the install 
 folder
 - install a service assembly containing a service unit with some endpoints : 
 copy the zip in the deploy folder
 - uninstall the service assembly :  delete the zip file
 - uninstall the component : delete the jar file
 Then you will see that some files are still locked on the wdir folder.
 Furthermore I use JSwat to remotely debug the JVM, with this tool you can see 
 that the ParentFirstClassloader of 
 the servicemix-jms component is still loaded.
 I also found that if a service assembly is not installed then this bug 
 doesn't occur.

-- 
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: (SM-712) Upgrade to xfire 1.2.2

2006-10-17 Thread Guillaume Nodet (JIRA)
 [ https://issues.apache.org/activemq/browse/SM-712?page=all ]

Guillaume Nodet resolved SM-712.


Resolution: Fixed
  Assignee: Guillaume Nodet

Author: gnodet
Date: Tue Oct 17 00:36:28 2006
New Revision: 464856

URL: http://svn.apache.org/viewvc?view=revrev=464856
Log:
SM-712: Upgrade to xfire-1.2.2

Modified:
   incubator/servicemix/branches/servicemix-3.0/pom.xml


Author: gnodet
Date: Tue Oct 17 00:36:12 2006
New Revision: 464855

URL: http://svn.apache.org/viewvc?view=revrev=464855
Log:
SM-712: Upgrade to xfire-1.2.2

Modified:
   incubator/servicemix/trunk/pom.xml


 Upgrade to xfire 1.2.2
 --

 Key: SM-712
 URL: https://issues.apache.org/activemq/browse/SM-712
 Project: ServiceMix
  Issue Type: Improvement
Reporter: Guillaume Nodet
 Assigned To: Guillaume Nodet
 Fix For: 3.0.1, 3.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] Resolved: (SM-711) Upgrade to woodstox 3.0.2

2006-10-17 Thread Guillaume Nodet (JIRA)
 [ https://issues.apache.org/activemq/browse/SM-711?page=all ]

Guillaume Nodet resolved SM-711.


Resolution: Fixed
  Assignee: Guillaume Nodet

Author: gnodet
Date: Tue Oct 17 00:34:25 2006
New Revision: 464854

URL: http://svn.apache.org/viewvc?view=revrev=464854
Log:
SM-711: Upgrade to woodstox 3.0.2

Modified:
   incubator/servicemix/branches/servicemix-3.0/pom.xml



Author: gnodet
Date: Tue Oct 17 00:33:56 2006
New Revision: 464853

URL: http://svn.apache.org/viewvc?view=revrev=464853
Log:
SM-711: Upgrade to woodstox 3.0.2

Modified:
   incubator/servicemix/trunk/pom.xml



 Upgrade to woodstox 3.0.2
 -

 Key: SM-711
 URL: https://issues.apache.org/activemq/browse/SM-711
 Project: ServiceMix
  Issue Type: Improvement
Reporter: Guillaume Nodet
 Assigned To: Guillaume Nodet
 Fix For: 3.0.1, 3.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: (SM-709) Upgrade to xbean 2.7 and Spring 2.0

2006-10-17 Thread Guillaume Nodet (JIRA)
[ 
https://issues.apache.org/activemq/browse/SM-709?page=comments#action_37210 ] 

Guillaume Nodet commented on SM-709:


Author: gnodet
Date: Tue Oct 17 00:28:20 2006
New Revision: 464850

URL: http://svn.apache.org/viewvc?view=revrev=464850
Log:
SM-709: Upgrade to xbean-2.7 and spring-2.0

Modified:
   incubator/servicemix/trunk/pom.xml


Author: gnodet
Date: Tue Oct 17 00:27:46 2006
New Revision: 464849

URL: http://svn.apache.org/viewvc?view=revrev=464849
Log:
SM-709: Upgrade to xbean-2.7 and spring-2.0

Modified:
   incubator/servicemix/branches/servicemix-3.0/pom.xml


 Upgrade to xbean 2.7 and Spring 2.0
 ---

 Key: SM-709
 URL: https://issues.apache.org/activemq/browse/SM-709
 Project: ServiceMix
  Issue Type: Improvement
Affects Versions: 3.0
Reporter: Guillaume Nodet
 Assigned To: Guillaume Nodet
 Fix For: 3.0.1, 3.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] Resolved: (SM-671) Use RI implementations for activation and javamail instead of geronimo ones

2006-10-17 Thread Guillaume Nodet (JIRA)
 [ https://issues.apache.org/activemq/browse/SM-671?page=all ]

Guillaume Nodet resolved SM-671.


Resolution: Fixed
  Assignee: Guillaume Nodet

Author: gnodet
Date: Tue Oct 17 02:27:32 2006
New Revision: 464872

URL: http://svn.apache.org/viewvc?view=revrev=464872
Log:
SM-671: Use RI implementation of mail and activation

Modified:
   incubator/servicemix/trunk/apache-servicemix/pom.xml
   incubator/servicemix/trunk/apache-servicemix/src/main/assembly/bin.xml


Author: gnodet
Date: Tue Oct 17 02:27:59 2006
New Revision: 464873

URL: http://svn.apache.org/viewvc?view=revrev=464873
Log:
SM-671: Use RI implementation of mail and activation

Modified:
   incubator/servicemix/branches/servicemix-3.0/apache-servicemix/pom.xml
   
incubator/servicemix/branches/servicemix-3.0/apache-servicemix/src/main/assembly/bin.xml


 Use RI implementations for activation and javamail instead of geronimo ones
 ---

 Key: SM-671
 URL: https://issues.apache.org/activemq/browse/SM-671
 Project: ServiceMix
  Issue Type: Task
  Components: servicemix-assembly
Reporter: Guillaume Nodet
 Assigned To: Guillaume Nodet
 Fix For: 3.0.1, 3.1




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




[jira] Created: (SM-713) make some time values configurable

2006-10-17 Thread Thomas Termin (JIRA)
make some time values configurable
--

 Key: SM-713
 URL: https://issues.apache.org/activemq/browse/SM-713
 Project: ServiceMix
  Issue Type: Improvement
  Components: servicemix-http
Reporter: Thomas Termin
Priority: Critical
 Attachments: patch

The maxIdleTime for the jetty connector as well as the suspend time for the 
consumer processor are not configurable and both are under certain cirumstances 
to low (long requests).

I added a patch where you can configure this values via JMX with the 
HttpConfigurationMBean. Hope this will help you. It works fine for us.

The suspent time should be higher than the maxIdleTime.

-- 
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: (SM-713) make some time values configurable

2006-10-17 Thread Guillaume Nodet (JIRA)
 [ https://issues.apache.org/activemq/browse/SM-713?page=all ]

Guillaume Nodet resolved SM-713.


Fix Version/s: 3.1
   Resolution: Fixed
 Assignee: Guillaume Nodet

Author: gnodet
Date: Tue Oct 17 02:55:56 2006
New Revision: 464883

URL: http://svn.apache.org/viewvc?view=revrev=464883
Log:
SM-713: Make time-out values configurable

Modified:
   
incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/HttpConfiguration.java
   
incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/HttpConfigurationMBean.java
   
incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/jetty/JettyContextManager.java
   
incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/processors/ConsumerProcessor.java



 make some time values configurable
 --

 Key: SM-713
 URL: https://issues.apache.org/activemq/browse/SM-713
 Project: ServiceMix
  Issue Type: Improvement
  Components: servicemix-http
Reporter: Thomas Termin
 Assigned To: Guillaume Nodet
Priority: Critical
 Fix For: 3.1

 Attachments: patch


 The maxIdleTime for the jetty connector as well as the suspend time for the 
 consumer processor are not configurable and both are under certain 
 cirumstances to low (long requests).
 I added a patch where you can configure this values via JMX with the 
 HttpConfigurationMBean. Hope this will help you. It works fine for us.
 The suspent time should be higher than the maxIdleTime.

-- 
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] Updated: (SM-695) Dynamic HTTP provider endpoint

2006-10-17 Thread Guillaume Nodet (JIRA)
 [ https://issues.apache.org/activemq/browse/SM-695?page=all ]

Guillaume Nodet updated SM-695:
---

Patch Info: [Patch Available]

 Dynamic HTTP provider endpoint
 --

 Key: SM-695
 URL: https://issues.apache.org/activemq/browse/SM-695
 Project: ServiceMix
  Issue Type: New Feature
  Components: servicemix-http
Affects Versions: 3.0
Reporter: James Lorenzen
Priority: Minor
 Attachments: HttpProviderTest.java, JbiConstants.java, 
 ProviderProcessor.java, ProviderProcessor.java


 It would be benficial to add functionaility to the HTTP BC to allow consumers 
 to specify the provider locationURI through a NormalizedMessage property.
 Please see this thread for related information: 
 http://www.nabble.com/http-endpoint-in-provider-mode%3A-dynamic-destination--tf1413771.html#a6721824
 Our team plans on adding some code to the HTTP BC that first looks to see if 
 the NormalizedMessage contains a specific property containing the value for 
 the destination. Therefore a consumer could create a new NormalizedMessage 
 and call setProperty to set the destination URI. If the HTTP BC detects this 
 property he routes the request to this URI; otherwise it continues as normal 
 and uses the locationURI specified in the xbean.xml file.
 We plan on making and testing this change in the next couple of days. After 
 which we will reply back with the modifications.

-- 
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: Form editors for Geronimo Deployment Plans

2006-10-17 Thread Shiva Kumar H R
Hi Sachin,Currently I am only concentrating on the UI design for the Geronimo Deployment Plan Editors. As such, the changes I have made only update the UI elements, and the code for updating the underlying deployment-plan is not yet written. I will open JIRAs once that code is also in place.
-- Thx,Shiva
On 10/15/06, Sachin Patel [EMAIL PROTECTED]
 wrote:
Thank you for your contributions. If you could, please open a JIRA and attach a diff for each work item.On Oct 12, 2006, at 7:14 AM, Shiva Kumar H R wrote:
Hi!My apologies for being out of communication for quite some time now. Enough time has been spent on sharpening the saw ... time to cut now. :-)
I am starting with the following changes/updations to the general layout of the Geronimo Deployment Plan Editor. Request your comments on the same. 1) updations to Deployment tab: Deployment Configuration will now have two additional sections, one for Hidden Classes and another for Non Overridable Classes. 
Snapshot-1.gif demonstrates this. This is to fit in sys:hidden-classes and sys:non-overridable-classes sub-elements of sys:environment in geronimo-web.xml. Snapshot-1b.gif shows the wizard that will be used for accepting the class/package names. 
2) updations to Dependency Wizard:The wizard that comes up when Add or Edit button in Dependencies section is clicked, is updated to include sys:import sub-element of sys:dependency. Also Artifact Type and Import Type are now combo lists. 
Snapshot-2.gif, Snapshot-2b.gif  Snapshot-2c.gif demonstrate this.I am working on updating other wizards and will post the snapshots here once ready.-- Thx,Shiva

 On 8/16/06, Sachin Patel [EMAIL PROTECTED] wrote:

 Awesome! This is exactly what is needed!On Aug 16, 2006, at 8:57 AM, Shiva Kumar H R wrote:Hello Sachin,Sorry for not being in touch for quite some time now. I have been going through Aaron Mulder's book on Geronimo 
v1.1, especially the chapters on Geronimo Deployment Plans. Apart from that I was also on vacation for two weeks. Not much progress has been made w.r.t. the design  devlp of Form editors for Geronimo Deployment Plans. 
I will bring in some focus into my work. Here is what I am planning to do next. Please suggest if I need to look into something else also. i) Complete the reading  understanding of Geronimo Deployment Plans from Aaron's book. 
ii) Look at the Deployment Plan Editors provided in other IDEs like Rational Application Developer or JBoss Eclipse IDE. iii) Come up with the initial design/layout of Form editors for Geronimo Deployment Plans. 
-- Thx,Shiva On 7/18/06, Sachin Patel 

 [EMAIL PROTECTED] wrote: Great!

 On Jul 18, 2006, at 8:37 AM, Shiva Kumar H R wrote:Hello Sachin,I now have the complete build setup for Geronimo Eclipse Plugin on my Windows machine (thanks to your article 

 http://cwiki.apache.org/confluence/display/GMOxDOC11/Geronimo+Eclipse+Plugin+FAQ ).I am planning to get started on developing/enhancing the Geronimo deployment plan editors. I am currently looking at  package 
org.apache.geronimo.st.ui.editors;  class SharedDeploymentPlanEditor;  class AbstractGeronimoDeploymentPlanEditor;Will keep you posted on my progress.-- Thx,Shiva

  

 

 

 

 -sachin   

 

 

 

 -sachin  Snapshot-1.gifSnapshot-1b.gif

Snapshot-2.gifSnapshot-2b.gifSnapshot-2c.gif 







-sachin 




[jira] Created: (AMQ-984) make the slave status of a broker available through JMX (in jdbc-master-slave mode)

2006-10-17 Thread Renaud Bruyeron (JIRA)
make the slave status of a broker available through JMX (in jdbc-master-slave 
mode)
-

 Key: AMQ-984
 URL: https://issues.apache.org/activemq/browse/AMQ-984
 Project: ActiveMQ
  Issue Type: Improvement
  Components: Broker
Affects Versions: 4.1
Reporter: Renaud Bruyeron
Priority: Minor
 Fix For: 4.1



Right now, it is not possible to know that a broker is in Attempting to 
acquire the exclusive lock to become the Master broker mode via JMX, even 
though this would be a natural place to find out.

Do you think it would be possible to expose the DatabaseLocker or the 
JDBCPersistenceAdapter over JMX so that a simple boolean isMaster() can be 
queried?

-- 
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: [VOTE] Release Servicemix 3.0.1

2006-10-17 Thread Philip Dodds

+1

On 10/16/06, Grant McDonald [EMAIL PROTECTED] wrote:

+1 from me too

-Original Message-
From: Ramon Buckland [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 17 October 2006 9:54 AM
To: servicemix-dev@geronimo.apache.org
Subject: Re: [VOTE] Release Servicemix 3.0.1

+1 from me

On Tue, 2006-10-17 at 00:43 +0200, Guillaume Nodet wrote:
 I'd like to start the release process for 3.0.1.
 The list of bugs fixed in 3.0.1 is available at

http://issues.apache.org/activemq/secure/IssueNavigator.jspa?view=decorator
=printablestart=0fixfor=11716mode=hidereset=truepid=10950tempMax=1000

 [ ] +1 Release servicemix 3.0.1
 [ ] 0 Abstain
 [ ] -1 Do not release servicemix 3.0.1

 Here's my +1





Re: geronimo on jconsole

2006-10-17 Thread Donald Woods

What connection settings did you use in JConsole to connect?
I'm trying to use JConsole from the same 1.5.0 JDK that I started a 
1.1.1 server, with the following connection settings as shown in your 
screen capture -

  JMX URL = service:jmx:rmi:///jndi/rmi://localhost:1099/
  User Name = system
  Password = manager

and the JConsole connection fails with the following exception -

  Exception in thread JConsole.addUrl java.lang.ClassCastException: 
com.sun.jndi.rmi.registry.RegistryContext incompatible with 
javax.management.remote.rmi.RMIServer
at 
javax.management.remote.rmi.RMIConnector.narrowJRMPServer(RMIConnector.java:1833)
at 
javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1828)
at 
javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1792)
at 
javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:274)
at 
javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:263)

at sun.tools.jconsole.ProxyClient.init(ProxyClient.java:143)
at 
sun.tools.jconsole.ProxyClient.getProxyClient(ProxyClient.java:113)

at sun.tools.jconsole.JConsole$2.run(JConsole.java:442)


-Donald

anita kulshreshtha wrote:

Hi All,
I have been playing around! To view a snapshot of geronimo from 
jconsole please see:

http://people.apache.org/~akulshreshtha/jconsole/geronimo.jpg
   please be sure to hit the zoom and scroll the image to the center.

Thanks
Anita


All-new Yahoo! Mail 
http://us.rd.yahoo.com/evt=43256/*http://advision.webevents.yahoo.com/mailbeta- 
Fire up a more powerful email and get things done faster.


smime.p7s
Description: S/MIME Cryptographic Signature


[jira] Created: (AMQ-985) TcpTransportFactory adds LoggingTransport after WireFormatNegotiator

2006-10-17 Thread Rob Lugt (JIRA)
TcpTransportFactory adds LoggingTransport after WireFormatNegotiator


 Key: AMQ-985
 URL: https://issues.apache.org/activemq/browse/AMQ-985
 Project: ActiveMQ
  Issue Type: Improvement
  Components: NMS (C# client)
Affects Versions: 4.0.2
 Environment: Windows
Reporter: Rob Lugt
 Assigned To: james strachan
Priority: Minor


The TcpTransportFactory class will insert a LoggingTransport filter into the 
transport chain if the useLogging=true attribute is set.  However, it currently 
adds the LoggingTransport after the WireFormatNegotiator, which means that the 
wire format negotiation packets are excluded from the log output.  This can be 
simply rectified by adding the LoggingTransport immediately after the 
TcpTransport.  e.g.

  public ITransport CreateTransport(Uri location) 
{
// Console.WriteLine(Opening socket to:  + host +  on port:  + 
port);
Socket socket = Connect(location.Host, location.Port);
TcpTransport tcpTransport = new TcpTransport(socket);
ITransport rc = tcpTransport;

// At present the URI is parsed for options by the 
ConnectionFactory
if (UseLogging)
{
rc = new LoggingTransport(rc);
}

rc = new WireFormatNegotiator(rc, tcpTransport.Wireformat);
...


-- 
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: geronimo on jconsole

2006-10-17 Thread anita kulshreshtha
   JMX URL = ""> The JMXConnector is not showing on the screen. The screen shots are for G started using -Dcom.sun.management.jmxremote in 1.5. If you run G in 1.4 you will only be able to see MBeans.ThanksAnitaDonald Woods [EMAIL PROTECTED] wrote: What connection settings did you use in JConsole to connect?I'm trying to use JConsole from the same 1.5.0 JDK that I started a 1.1.1 server, with the following connection settings as shown in your screen capture -   JMX URL = "">   User Name = system   Password = managerand the JConsole connection fails with the following exception -   Exception in thread "JConsole.addUrl"
 java.lang.ClassCastException: com.sun.jndi.rmi.registry.RegistryContext incompatible with javax.management.remote.rmi.RMIServer at javax.management.remote.rmi.RMIConnector.narrowJRMPServer(RMIConnector.java:1833) at javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1828) at javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1792) at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:274) at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:263) at sun.tools.jconsole.ProxyClient.(ProxyClient.java:143) at sun.tools.jconsole.ProxyClient.getProxyClient(ProxyClient.java:113) at sun.tools.jconsole.JConsole$2.run(JConsole.java:442)-Donaldanita kulshreshtha wrote: Hi All, I have been playing around! To view a snapshot
 of geronimo from  jconsole please see: http://people.apache.org/~akulshreshtha/jconsole/geronimo.jpgplease be sure to hit the zoom and scroll the image to the center.  Thanks Anita   All-new Yahoo! Mail  -  Fire up a more powerful email and get things done faster. 
		Do you Yahoo!? Everyone is raving about the  all-new Yahoo! Mail.

JConsole Layout

2006-10-17 Thread Matt Hogstrom

Anita,

I deleted the e-mail you previously sent on the jConsole layout.  I'd  
like to help with the monitoring effort a bit... can you reforward  
your current layout image?


Matt Hogstrom
[EMAIL PROTECTED]





[jira] Updated: (GERONIMO-2413) Add a Certification Authority (CA) portlet to Geronimo console

2006-10-17 Thread Vamsavardhana Reddy (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-2413?page=all ]

Vamsavardhana Reddy updated GERONIMO-2413:
--

Attachment: GERONIMO-2413-v1.2.patch

GERONIMO-2413-v1.2.patch:  Includes CA portlet and CA Helper application.

 Add a Certification Authority (CA) portlet to Geronimo console
 --

 Key: GERONIMO-2413
 URL: http://issues.apache.org/jira/browse/GERONIMO-2413
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: console, security
Reporter: Vamsavardhana Reddy
 Fix For: 1.2, 1.x

 Attachments: 02.ca-initialization-enter-details.JPG, 
 07.issue-certificate-show-csr-details.JPG, 
 09.issue-certificate-successful.JPG, GERONIMO-2413-revised.patch, 
 GERONIMO-2413-v1.2.patch, GERONIMO-2413.patch, GeronimoCA.zip


 A Certification Authority portlet will be very useful.  A full fledged CA may 
 be a long way to go.  But what ever minimum function is required to process 
 CSR's etc. is not hard and the users can issue their own digital certificates 
 instead of getting trial certificates from some CA. 

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




[jira] Commented: (SM-695) Dynamic HTTP provider endpoint

2006-10-17 Thread James Lorenzen (JIRA)
[ 
https://issues.apache.org/activemq/browse/SM-695?page=comments#action_37216 ] 

James Lorenzen commented on SM-695:
---

I am new to this.
What does it mean when you updated this item to Patch Available?

 Dynamic HTTP provider endpoint
 --

 Key: SM-695
 URL: https://issues.apache.org/activemq/browse/SM-695
 Project: ServiceMix
  Issue Type: New Feature
  Components: servicemix-http
Affects Versions: 3.0
Reporter: James Lorenzen
Priority: Minor
 Attachments: HttpProviderTest.java, JbiConstants.java, 
 ProviderProcessor.java, ProviderProcessor.java


 It would be benficial to add functionaility to the HTTP BC to allow consumers 
 to specify the provider locationURI through a NormalizedMessage property.
 Please see this thread for related information: 
 http://www.nabble.com/http-endpoint-in-provider-mode%3A-dynamic-destination--tf1413771.html#a6721824
 Our team plans on adding some code to the HTTP BC that first looks to see if 
 the NormalizedMessage contains a specific property containing the value for 
 the destination. Therefore a consumer could create a new NormalizedMessage 
 and call setProperty to set the destination URI. If the HTTP BC detects this 
 property he routes the request to this URI; otherwise it continues as normal 
 and uses the locationURI specified in the xbean.xml file.
 We plan on making and testing this change in the next couple of days. After 
 which we will reply back with the modifications.

-- 
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: (GERONIMO-2413) Add a Certification Authority (CA) portlet to Geronimo console

2006-10-17 Thread Vamsavardhana Reddy (JIRA)
[ 
http://issues.apache.org/jira/browse/GERONIMO-2413?page=comments#action_12442928
 ] 

Vamsavardhana Reddy commented on GERONIMO-2413:
---

Here is a scenario I have tested.
Step 1.  Setup CA by entering CA Name details etc.
Step 2.  Generate a CSR from geronimo-default keystore and process the server 
certificate request using Issue New Certificate link in CA portlet.
Step 3.  Import CA's certificate as trusted and the CA reply.
Step 4.  Setup an HTTPS Connector configured for client authentication.
Step 5.  Start the CA Helper application from Web App WARs portlet

In a second browser window,
Step 6.  Access the CA Helper Application at http://localhost:8080/CAHelper 
through a web browser that supports KEYGEN tag.  Internet Explorer does not 
support KEYGEN tag.
Step 7.  Submit a Certificate Request through web brower using Request 
Certificate link.  Upon submission the request shows up in Requests to be 
verified page in CA portlet.  NOTE:  Make a note of the request id as it will 
be required to download the cerfiticate issued by the CA.

In CA portlet,
Step 8.  Approve the request through CA portllet using Requests to be 
verified link.  Approved requests showup in Requests to be fulfilled page.
Step 9.  Process the request from Requests to be fulfilled page and issue 
certificate.

In the CA Helper window,
Step 10.  Import CA's certificate into web browser suing Download CA 
certificate link.
Step 11.  Install personal certificate using the Download Certificate link 
and request id from Step 7 above.
Step 12.  Access the verify certificate link to verify that the certificate is 
downloaded and installed.

Summary of the scenario:  CA is setup; a certificate request is submitted 
through web browser and issued certificate is downloaded into the web browser.

 Add a Certification Authority (CA) portlet to Geronimo console
 --

 Key: GERONIMO-2413
 URL: http://issues.apache.org/jira/browse/GERONIMO-2413
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: console, security
Reporter: Vamsavardhana Reddy
 Fix For: 1.2, 1.x

 Attachments: 02.ca-initialization-enter-details.JPG, 
 07.issue-certificate-show-csr-details.JPG, 
 09.issue-certificate-successful.JPG, GERONIMO-2413-revised.patch, 
 GERONIMO-2413-v1.2.patch, GERONIMO-2413.patch, GeronimoCA.zip


 A Certification Authority portlet will be very useful.  A full fledged CA may 
 be a long way to go.  But what ever minimum function is required to process 
 CSR's etc. is not hard and the users can issue their own digital certificates 
 instead of getting trial certificates from some CA. 

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




[jira] Commented: (GERONIMO-2015) Let's replace JKS to PKCS12 key store type

2006-10-17 Thread Nikolay Chugunov (JIRA)
[ 
http://issues.apache.org/jira/browse/GERONIMO-2015?page=comments#action_12442937
 ] 

Nikolay Chugunov commented on GERONIMO-2015:


Vamsavardhana,
As following from your stack trace JKSToPKCS12 class should invoke 
setCertificateEntry method. But it does't not exist in the class.
I verify that the class works fine on 1.4.

 Let's replace JKS to PKCS12 key store type
 --

 Key: GERONIMO-2015
 URL: http://issues.apache.org/jira/browse/GERONIMO-2015
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: security
Reporter: Nikolay Chugunov
 Fix For: 1.2

 Attachments: jksToPKCS12-1.1.1.patch, JKSToPKCS12.java, 
 jksToPKCS12.patch, keystore


 Hello
 Let's replace JKS to PKCS12 key store type; because PKCS12 is widely used key 
 store and Geronimo may not work on non-Sun VMs.
 To fix this problem I have created the patch for Geronimo sources.
 In brief the patch (attached) replaces JKS to PKCS12 key store type in 
 configurations files. 
 PKCS12 format of key store file is not java-specific and can be created and 
 read by other programs, e.g. Internet Explorer. In addition PKCS12 exists in 
 Bouncy Castle (http://www.bouncycastle.org) security provider, while JKS is 
 Sun specific key store and does not exist in Bouncy Castle.
 Also it is needed to replace JKS to PKCS12 keystore file (attached) to 
 assemblies/j2ee-tomcat-server/src/var/security, 
 assemblies/j2ee-installer/src/var/security, 
 assemblies/j2ee-jetty-server/src/var/security directories. Key store file was 
 generating using JKSToPKCS12 class (attached). This class transfers key and 
 certificate of Geronimo from JKS to PKCS12.
 After I apply this patch to Geronimo 1.0 sources and build Geronimo I can 
 login to Geronimo console over https.

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




Trying to use the new activemq-cpp makefiles, some issues remain for Solaris

2006-10-17 Thread Bish, Tim

Hiram.

I've been hacking away trying to get a build on Solaris 10 using the
newer automake stuff.  So far I've had some success but still can't
build the library.  

There seems to be some issues with the way sun has set things up on the
sun box. I had to hack up a libstdc++.la as described in this article.
http://forum.sun.com/jive/thread.jspa?threadID=73150

I deleted the old makefiles so that gmake could find the Makefile
versions.

I end up with this error on attempting to build the find library file.  

g++ -g -O2 -o .libs/example main.o  ../main/.libs/libactivemq-cpp.so
/usr/sfw/lib/libstdc++.so -lc -L/usr/sfw/lib -lm -lpthread -luuid -Wl,-R
-Wl,/usr/local/lib -Wl,-R -Wl,/usr/sfw/lib
ld: warning: file /usr/sfw/lib/libstdc++.so: attempted multiple
inclusion of file
Undefined   first referenced
 symbol in file
nanosleep   ../main/.libs/libactivemq-cpp.so

I added an include of time.h to Thread.cpp which is the only code that
uses nanosleep, and that doesn't seem to help.  According to the man
nanosleep this is where it should come from on SUN.  

When I try and use the Solaris Compiler I get really crazy errors that
don't seem to make any sense.  

Everything builds fine using the older Makefiles, so I think that the
source code is okay.

Any ideas?



[jira] Commented: (GERONIMO-2015) Let's replace JKS to PKCS12 key store type

2006-10-17 Thread Vamsavardhana Reddy (JIRA)
[ 
http://issues.apache.org/jira/browse/GERONIMO-2015?page=comments#action_12442944
 ] 

Vamsavardhana Reddy commented on GERONIMO-2015:
---

I have written a simple java class to translate a JKS keystore to PKCS12 
keystore.  The class would iterate thru all key entries in JKS keystore and 
call setKeyEntry on the PKCS12 keystore. Then it will iterate thru all 
certificate entries in the JKS keystore and call setCertificateEntry() on the 
PKCS12 keystore.  The Exception I logged above means that setCertificateEntry() 
on a PKCS12 keystore is not supported in Sun JDK 142.  To reproduce the 
exception, invoke setCertificateEntry() method on a PKCS12 keystore KeyStore 
object in Sun JDK 1.4.2.

 Let's replace JKS to PKCS12 key store type
 --

 Key: GERONIMO-2015
 URL: http://issues.apache.org/jira/browse/GERONIMO-2015
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: security
Reporter: Nikolay Chugunov
 Fix For: 1.2

 Attachments: jksToPKCS12-1.1.1.patch, JKSToPKCS12.java, 
 jksToPKCS12.patch, keystore


 Hello
 Let's replace JKS to PKCS12 key store type; because PKCS12 is widely used key 
 store and Geronimo may not work on non-Sun VMs.
 To fix this problem I have created the patch for Geronimo sources.
 In brief the patch (attached) replaces JKS to PKCS12 key store type in 
 configurations files. 
 PKCS12 format of key store file is not java-specific and can be created and 
 read by other programs, e.g. Internet Explorer. In addition PKCS12 exists in 
 Bouncy Castle (http://www.bouncycastle.org) security provider, while JKS is 
 Sun specific key store and does not exist in Bouncy Castle.
 Also it is needed to replace JKS to PKCS12 keystore file (attached) to 
 assemblies/j2ee-tomcat-server/src/var/security, 
 assemblies/j2ee-installer/src/var/security, 
 assemblies/j2ee-jetty-server/src/var/security directories. Key store file was 
 generating using JKSToPKCS12 class (attached). This class transfers key and 
 certificate of Geronimo from JKS to PKCS12.
 After I apply this patch to Geronimo 1.0 sources and build Geronimo I can 
 login to Geronimo console over https.

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




[jira] Commented: (AMQ-986) Homepage download page points to wrong directory for 4.x

2006-10-17 Thread JIRA
[ 
https://issues.apache.org/activemq/browse/AMQ-986?page=comments#action_37217 ] 

Bernhard Wellhöfer commented on AMQ-986:


Please see the discussion under 
http://www.nabble.com/Where-to-find-org.apache.activemq.spring.ActiveMQConnectionFactory-tf2457849.html
 .

 Homepage download page points to wrong directory for 4.x
 

 Key: AMQ-986
 URL: https://issues.apache.org/activemq/browse/AMQ-986
 Project: ActiveMQ
  Issue Type: Bug
  Components: Documentation
Affects Versions: 4.x
Reporter: Bernhard Wellhöfer

 The www.activemq.org web page points for the 4.1 distro under 
 Download/Latest Release to the wrong download directory.
 Currently it points to 
 http://people.apache.org/repository/incubator-activemq/distributions, but 
 here the oldest distro is from Jul 2006. The ocrrect URL is 
 http://people.apache.org/maven-snapshot-repository/org/apache/activemq/apache-activemq/4.1-incubator-SNAPSHOT.

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




[jira] Created: (AMQ-986) Homepage download page points to wrong directory for 4.x

2006-10-17 Thread JIRA
Homepage download page points to wrong directory for 4.x


 Key: AMQ-986
 URL: https://issues.apache.org/activemq/browse/AMQ-986
 Project: ActiveMQ
  Issue Type: Bug
  Components: Documentation
Affects Versions: 4.x
Reporter: Bernhard Wellhöfer


The www.activemq.org web page points for the 4.1 distro under Download/Latest 
Release to the wrong download directory.

Currently it points to 
http://people.apache.org/repository/incubator-activemq/distributions, but here 
the oldest distro is from Jul 2006. The ocrrect URL is 
http://people.apache.org/maven-snapshot-repository/org/apache/activemq/apache-activemq/4.1-incubator-SNAPSHOT.



-- 
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: [VOTE] Release Servicemix 3.0.1

2006-10-17 Thread Rob Davies

+1
On 17 Oct 2006, at 14:45, Philip Dodds wrote:


+1

On 10/16/06, Grant McDonald [EMAIL PROTECTED] wrote:

+1 from me too

-Original Message-
From: Ramon Buckland [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 17 October 2006 9:54 AM
To: servicemix-dev@geronimo.apache.org
Subject: Re: [VOTE] Release Servicemix 3.0.1

+1 from me

On Tue, 2006-10-17 at 00:43 +0200, Guillaume Nodet wrote:
 I'd like to start the release process for 3.0.1.
 The list of bugs fixed in 3.0.1 is available at

http://issues.apache.org/activemq/secure/IssueNavigator.jspa? 
view=decorator
=printablestart=0fixfor=11716mode=hidereset=truepid=10950tempMa 
x=1000


 [ ] +1 Release servicemix 3.0.1
 [ ] 0 Abstain
 [ ] -1 Do not release servicemix 3.0.1

 Here's my +1







[jira] Commented: (SM-695) Dynamic HTTP provider endpoint

2006-10-17 Thread Guillaume Nodet (JIRA)
[ 
https://issues.apache.org/activemq/browse/SM-695?page=comments#action_37218 ] 

Guillaume Nodet commented on SM-695:


Nothing particularly, but as a patch is available, the flag should be set.
It allows to filter on issues with patches, which should be applied first.
I will commit this patch asap.

 Dynamic HTTP provider endpoint
 --

 Key: SM-695
 URL: https://issues.apache.org/activemq/browse/SM-695
 Project: ServiceMix
  Issue Type: New Feature
  Components: servicemix-http
Affects Versions: 3.0
Reporter: James Lorenzen
Priority: Minor
 Attachments: HttpProviderTest.java, JbiConstants.java, 
 ProviderProcessor.java, ProviderProcessor.java


 It would be benficial to add functionaility to the HTTP BC to allow consumers 
 to specify the provider locationURI through a NormalizedMessage property.
 Please see this thread for related information: 
 http://www.nabble.com/http-endpoint-in-provider-mode%3A-dynamic-destination--tf1413771.html#a6721824
 Our team plans on adding some code to the HTTP BC that first looks to see if 
 the NormalizedMessage contains a specific property containing the value for 
 the destination. Therefore a consumer could create a new NormalizedMessage 
 and call setProperty to set the destination URI. If the HTTP BC detects this 
 property he routes the request to this URI; otherwise it continues as normal 
 and uses the locationURI specified in the xbean.xml file.
 We plan on making and testing this change in the next couple of days. After 
 which we will reply back with the modifications.

-- 
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: (GERONIMO-2015) Let's replace JKS to PKCS12 key store type

2006-10-17 Thread Nikolay Chugunov (JIRA)
[ 
http://issues.apache.org/jira/browse/GERONIMO-2015?page=comments#action_12442965
 ] 

Nikolay Chugunov commented on GERONIMO-2015:


Vamsavardhana,
Could you send code, you have written above

 Let's replace JKS to PKCS12 key store type
 --

 Key: GERONIMO-2015
 URL: http://issues.apache.org/jira/browse/GERONIMO-2015
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: security
Reporter: Nikolay Chugunov
 Fix For: 1.2

 Attachments: jksToPKCS12-1.1.1.patch, JKSToPKCS12.java, 
 jksToPKCS12.patch, keystore


 Hello
 Let's replace JKS to PKCS12 key store type; because PKCS12 is widely used key 
 store and Geronimo may not work on non-Sun VMs.
 To fix this problem I have created the patch for Geronimo sources.
 In brief the patch (attached) replaces JKS to PKCS12 key store type in 
 configurations files. 
 PKCS12 format of key store file is not java-specific and can be created and 
 read by other programs, e.g. Internet Explorer. In addition PKCS12 exists in 
 Bouncy Castle (http://www.bouncycastle.org) security provider, while JKS is 
 Sun specific key store and does not exist in Bouncy Castle.
 Also it is needed to replace JKS to PKCS12 keystore file (attached) to 
 assemblies/j2ee-tomcat-server/src/var/security, 
 assemblies/j2ee-installer/src/var/security, 
 assemblies/j2ee-jetty-server/src/var/security directories. Key store file was 
 generating using JKSToPKCS12 class (attached). This class transfers key and 
 certificate of Geronimo from JKS to PKCS12.
 After I apply this patch to Geronimo 1.0 sources and build Geronimo I can 
 login to Geronimo console over https.

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




Re: [VOTE] Release XBean 2.7

2006-10-17 Thread David Jencks

-1

xbean-naming has a dependency on geronimo-naming which must be  
removed before it can be released.  geronimo-naming uses xbean-naming.


thanks
david jencks

On Oct 16, 2006, at 10:32 AM, Guillaume Nodet wrote:


As proposed in the earlier discussion, I start
a vote about releasing xbean-2.7 from the
current svn head.  This will enable to use
maven release plugin to directly upload the
release to the maven repository.

[ ] +1 release xbean 2.7 from current snapshot
[ ] 0
[ ] -1 do not release xbean

Here's my +1

--
Cheers,
Guillaume Nodet




Re: JConsole Layout

2006-10-17 Thread anita kulshreshtha
Hi Matt, Here is the link:http://people.apache.org/~akulshreshtha/jconsole/geronimo.jpg.  I am looking at mc4j today.  So far jconsole looks better.. Let me know if you want snapshots from mc4j.ThanksAnitaMatt Hogstrom [EMAIL PROTECTED] wrote: Anita,I deleted the e-mail you previously sent on the jConsole layout.  I'd  like to help with the monitoring effort a bit... can you reforward  your current layout image?Matt Hogstrom[EMAIL PROTECTED] 
		Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls.  Great rates starting at 1¢/min.

Re: [VOTE] Release Servicemix 3.0.1

2006-10-17 Thread James Strachan

+1

On 10/16/06, Guillaume Nodet [EMAIL PROTECTED] wrote:

I'd like to start the release process for 3.0.1.
The list of bugs fixed in 3.0.1 is available at
http://issues.apache.org/activemq/secure/IssueNavigator.jspa?view=decorator=printablestart=0fixfor=11716mode=hidereset=truepid=10950tempMax=1000

[ ] +1 Release servicemix 3.0.1
[ ] 0 Abstain
[ ] -1 Do not release servicemix 3.0.1

Here's my +1

--
Cheers,
Guillaume Nodet




--

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


Re: [jira] Commented: (GERONIMO-2015) Let's replace JKS to PKCS12 key store type

2006-10-17 Thread Vamsavardhana Reddy
 KeyStore jks = KeyStore.getInstance(JKS);
 KeyStore pkcs12 = KeyStore.getInstance(PKCS12);
 FileInputStream fin = new FileInputStream(inFile);
 jks.load(fin, password);
 fin.close();
 System.out.println(Loaded input keystore +inFile);
 pkcs12.load(null, null);
 for(Enumeration e = jks.aliases(); e.hasMoreElements(); ) {
 String alias = (String) e.nextElement();
 if(jks.isCertificateEntry(alias)) {

pkcs12.setCertificateEntry(alias, jks.getCertificate(alias));
 } else {

pkcs12.setKeyEntry(alias, jks.getKey(alias, password), password,
jks.getCertificateChain(alias));
 }
 }
 FileOutputStream fout = new FileOutputStream(outFile);
 pkcs12.store(fout, password);
 fout.close();
On 10/17/06, Nikolay Chugunov (JIRA) dev@geronimo.apache.org wrote:
[ http://issues.apache.org/jira/browse/GERONIMO-2015?page=comments#action_12442965 ]Nikolay Chugunov commented on GERONIMO-2015:
Vamsavardhana,Could you send code, you have written above Let's replace JKS to PKCS12 key store type --
 Key: GERONIMO-2015
URL: http://issues.apache.org/jira/browse/GERONIMO-2015 Project: GeronimoIssue Type: ImprovementSecurity Level: public(Regular issues)
Components: securityReporter: Nikolay Chugunov Fix For: 1.2
Attachments: jksToPKCS12-1.1.1.patch, JKSToPKCS12.java,
jksToPKCS12.patch, keystore Hello Let's
replace JKS to PKCS12 key store type; because PKCS12 is widely used key
store and Geronimo may not work on non-Sun VMs. To fix this problem I have created the patch for Geronimo sources. In brief the patch (attached) replaces JKS to PKCS12 key store type in configurations files.

PKCS12 format of key store file is not java-specific and can be created
and read by other programs, e.g. Internet Explorer. In addition PKCS12
exists in Bouncy Castle (http://www.bouncycastle.org) security
provider, while JKS is Sun specific key store and does not exist in
Bouncy Castle. Also it is needed to replace JKS to PKCS12 keystore file (attached) to assemblies/j2ee-tomcat-server/src/var/security, assemblies/j2ee-installer/src/var/security, assemblies/j2ee-jetty-server/src/var/security
directories. Key store file was generating using JKSToPKCS12 class
(attached). This class transfers key and certificate of Geronimo from
JKS to PKCS12. After I apply this patch to Geronimo 1.0 sources and build Geronimo I can login to Geronimo console over https.--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: Geronimo Liferay Plugins

2006-10-17 Thread Donald Woods
Is there anyway you change the geronimo-plugin.xml file to remove the 
hard coded dependency on Derby 10.1.1.0?  For the IBM WASCE release 
based on Geronimo 1.1.1, this causes the plug-in to not install, as we 
use a newer level of Derby (IBM Cloudscape 10.1.3.2) and the referenced 
level of Derby is not hosted on your server.  Maybe you can change -

   dependencyorg.apache.derby/derby/10.1.1.0/jar/dependency
to be
   dependencyorg.apache.derby/derby//jar/dependency
or
   dependencygeronimo/system-database//car/dependency
or drop it all together?


-Donald


Brian Chan wrote:

Ok. Made the dir browseable.

Will be happy to share the PPTs with you once I finish them.

--
Brian Chan
Chief Software Architect
Liferay, Inc.
Enterprise. Open Source. For Life.

On 10/16/06 5:10 AM, Jacek Laskowski [EMAIL PROTECTED] mailto: 
[EMAIL PROTECTED] wrote:


On 10/14/06, Brian Chan  wrote:


The latest Liferay portal plugins are now available on.

http://geronimo.liferay.com/plugins

It'd be great if we can add it to the default list of available plugin
repositories for Geronimo 1.2 and on.


I think it's doable ;-) I'l start a vote about it in a separate mail.

In the meantime, could you enable the repo to be browsable? I'm
getting the following error msg:

Forbidden

You don't have permission to access /plugins/ on this server.


I'm quite impressed with Geronimo's plugin architecture and will be demoing
this feature in my upcoming talks/conferences as we promote our
Liferay+Geronimo.


Would you share the presentation with us? I'd be glad if I'd be able
to showcase it to a local java user group - Warszawa-JUG and don't
bother with slides and such.

Well, some documentation pages would be of help, too ;-)

Jacek

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


smime.p7s
Description: S/MIME Cryptographic Signature


Re: Geronimo Liferay Plugins

2006-10-17 Thread Aaron Mulder

Just a note -- if you change the Derby dependency, it's best to change
it in the original deployment plan for the Geronimo module, update the
plugin metadata, and build a new plugin file (CAR).  Ideally, both the
serialized CAR metadata and the XML plugin metadata will include the
same dependency (e.g. without the version number).  If you just change
the XML without changing the original deployment plan and regenerating
the CAR, then the serialized data will likely still have the versioned
dependency.

Thanks,
Aaron

On 10/17/06, Donald Woods [EMAIL PROTECTED] wrote:

Is there anyway you change the geronimo-plugin.xml file to remove the
hard coded dependency on Derby 10.1.1.0?  For the IBM WASCE release
based on Geronimo 1.1.1, this causes the plug-in to not install, as we
use a newer level of Derby (IBM Cloudscape 10.1.3.2) and the referenced
level of Derby is not hosted on your server.  Maybe you can change -
dependencyorg.apache.derby/derby/10.1.1.0/jar/dependency
to be
dependencyorg.apache.derby/derby//jar/dependency
or
dependencygeronimo/system-database//car/dependency
or drop it all together?


-Donald


Brian Chan wrote:
 Ok. Made the dir browseable.

 Will be happy to share the PPTs with you once I finish them.

 --
 Brian Chan
 Chief Software Architect
 Liferay, Inc.
 Enterprise. Open Source. For Life.

 On 10/16/06 5:10 AM, Jacek Laskowski [EMAIL PROTECTED] mailto:
 [EMAIL PROTECTED] wrote:

 On 10/14/06, Brian Chan  wrote:

 The latest Liferay portal plugins are now available on.

 http://geronimo.liferay.com/plugins

 It'd be great if we can add it to the default list of available plugin
 repositories for Geronimo 1.2 and on.

 I think it's doable ;-) I'l start a vote about it in a separate mail.

 In the meantime, could you enable the repo to be browsable? I'm
 getting the following error msg:

 Forbidden

 You don't have permission to access /plugins/ on this server.

 I'm quite impressed with Geronimo's plugin architecture and will be demoing
 this feature in my upcoming talks/conferences as we promote our
 Liferay+Geronimo.

 Would you share the presentation with us? I'd be glad if I'd be able
 to showcase it to a local java user group - Warszawa-JUG and don't
 bother with slides and such.

 Well, some documentation pages would be of help, too ;-)

 Jacek

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





[jira] Commented: (GERONIMO-2413) Add a Certification Authority (CA) portlet to Geronimo console

2006-10-17 Thread Vamsavardhana Reddy (JIRA)
[ 
http://issues.apache.org/jira/browse/GERONIMO-2413?page=comments#action_12443025
 ] 

Vamsavardhana Reddy commented on GERONIMO-2413:
---

How do you remove/edit CA info once configured?

During the setup, CA (let me call it Geronimo CA) uses a self-signed 
certificate.  If Geronimo CA decides to get certified by another CA, Geronimo 
CA can import its certificate into 'ca-keystore' using the keystore portlet.  
If Geronimo CA's certificate changes, it should be published again using the 
Publish CA Certificate link in CA Portlet.


 Add a Certification Authority (CA) portlet to Geronimo console
 --

 Key: GERONIMO-2413
 URL: http://issues.apache.org/jira/browse/GERONIMO-2413
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: console, security
Reporter: Vamsavardhana Reddy
 Fix For: 1.2, 1.x

 Attachments: 02.ca-initialization-enter-details.JPG, 
 07.issue-certificate-show-csr-details.JPG, 
 09.issue-certificate-successful.JPG, GERONIMO-2413-revised.patch, 
 GERONIMO-2413-v1.2.patch, GERONIMO-2413.patch, GeronimoCA.zip


 A Certification Authority portlet will be very useful.  A full fledged CA may 
 be a long way to go.  But what ever minimum function is required to process 
 CSR's etc. is not hard and the users can issue their own digital certificates 
 instead of getting trial certificates from some CA. 

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




Re: [VOTE] Release XBean 2.7

2006-10-17 Thread Dain Sundstrom
I removed the dependency on geronimo-naming.  The dep was only there  
so that xbean would use the fast dereference code of the geronimo  
simple reference.  I made the Geronimo SimpleReference an empty  
subclass of the XBean SimpleReference so the XBean code still call  
the fast dereference methods of Geronimo references.


-dain

On Oct 17, 2006, at 9:31 AM, David Jencks wrote:


-1

xbean-naming has a dependency on geronimo-naming which must be  
removed before it can be released.  geronimo-naming uses xbean-naming.


thanks
david jencks

On Oct 16, 2006, at 10:32 AM, Guillaume Nodet wrote:


As proposed in the earlier discussion, I start
a vote about releasing xbean-2.7 from the
current svn head.  This will enable to use
maven release plugin to directly upload the
release to the maven repository.

[ ] +1 release xbean 2.7 from current snapshot
[ ] 0
[ ] -1 do not release xbean

Here's my +1

--
Cheers,
Guillaume Nodet




Daytrader deployment plans?

2006-10-17 Thread Christopher Blythe
All...I'm a little confused about the Daytrader deployment plans riddled throughout the source tree and was wondering if someone could clear up my confusion?Under the tags/1.1.0 and branches/1.1 source trees, the 
tomcat-plan.xml and jetty-plan.xml are located and I have been using these on Geronimo 1.1 without a problem.However, if I look under trunk, these files are no where to be found. Instead, it still looks like the old 
1.0 deployment plans are located there.Can anyone clarify?Thanks...Chris


Re: Geronimo Liferay Plugins

2006-10-17 Thread Paul McMahan

Donald, would there be any concerns with letting the plugin dependency
system automatically download and install derby 10.1.1.0 alongside
10.1.3.2 in WAS CE?  If that works for you then that could be
accomplished by applying this patch to
http://geronimo.liferay.com/plugins/geronimo-plugins.xml :

49a50

  default-repositoryhttp://www.ibiblio.org/maven2//default-repository


Otherwise, as Aaron said the modules should be reinstalled and
re-exported as plugins alongside the changes you requested to the
dependency metadata.

Best wishes,
Paul


On 10/17/06, Aaron Mulder [EMAIL PROTECTED] wrote:

Just a note -- if you change the Derby dependency, it's best to change
it in the original deployment plan for the Geronimo module, update the
plugin metadata, and build a new plugin file (CAR).  Ideally, both the
serialized CAR metadata and the XML plugin metadata will include the
same dependency (e.g. without the version number).  If you just change
the XML without changing the original deployment plan and regenerating
the CAR, then the serialized data will likely still have the versioned
dependency.

Thanks,
 Aaron



Re: [VOTE] Release Servicemix 3.0.1

2006-10-17 Thread Dain Sundstrom

+1

-dain

On Oct 16, 2006, at 3:43 PM, Guillaume Nodet wrote:


I'd like to start the release process for 3.0.1.
The list of bugs fixed in 3.0.1 is available at
http://issues.apache.org/activemq/secure/IssueNavigator.jspa? 
view=decorator=printablestart=0fixfor=11716mode=hidereset=truepi 
d=10950tempMax=1000


[ ] +1 Release servicemix 3.0.1
[ ] 0 Abstain
[ ] -1 Do not release servicemix 3.0.1

Here's my +1

--
Cheers,
Guillaume Nodet




Re: Geronimo Liferay Plugins

2006-10-17 Thread Aaron Mulder

On 10/17/06, Paul McMahan [EMAIL PROTECTED] wrote:

Otherwise, as Aaron said the modules should be reinstalled and
re-exported as plugins alongside the changes you requested to the
dependency metadata.


I was actually saying that whoever originally created the plugins (and
therefore has the Geronimo plans used to deploy the modules in the
first place) should update the dependency elements used in those
plans and recreate the CAR files.  It's not so easy to do that if you
are only dealing with the plugin binaries.

Thanks,
Aaron


On 10/17/06, Aaron Mulder [EMAIL PROTECTED] wrote:
 Just a note -- if you change the Derby dependency, it's best to change
 it in the original deployment plan for the Geronimo module, update the
 plugin metadata, and build a new plugin file (CAR).  Ideally, both the
 serialized CAR metadata and the XML plugin metadata will include the
 same dependency (e.g. without the version number).  If you just change
 the XML without changing the original deployment plan and regenerating
 the CAR, then the serialized data will likely still have the versioned
 dependency.

 Thanks,
  Aaron




[jira] Commented: (AMQ-767) avoid use of XHTML in activemq-web-console so things work great in IE 6

2006-10-17 Thread Christopher G. Stach II (JIRA)
[ 
https://issues.apache.org/activemq/browse/AMQ-767?page=comments#action_37219 ] 

Christopher G. Stach II commented on AMQ-767:
-

All of our XHTML works perfectly in IE 6.  What's the issue?

 avoid use of XHTML in activemq-web-console so things work great in IE 6
 ---

 Key: AMQ-767
 URL: https://issues.apache.org/activemq/browse/AMQ-767
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 4.0.1
Reporter: 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




Re: Geronimo Liferay Plugins

2006-10-17 Thread Paul McMahan

Right, that's a better way of putting it -- thanks for the
clarification Aaron.  So to sum up, I think the two choices we've
discussed so far are:
1.)  add the www.ibiblio.org/maven2 repository to geronimo-plugins.xml
2.)  remove the Derby version number from the dependency element in
the connector's original deployment plan and then recreate the CAR
file.  One way to do that is to redeploy the modified connector into
geronimo and then export it as a plugin using the console. Then
replace the connector plugin in the repo and remove the Derby version
number from geronimo-plugins.xml.

Best wishes,
Paul

On 10/17/06, Aaron Mulder [EMAIL PROTECTED] wrote:

On 10/17/06, Paul McMahan [EMAIL PROTECTED] wrote:
 Otherwise, as Aaron said the modules should be reinstalled and
 re-exported as plugins alongside the changes you requested to the
 dependency metadata.

I was actually saying that whoever originally created the plugins (and
therefore has the Geronimo plans used to deploy the modules in the
first place) should update the dependency elements used in those
plans and recreate the CAR files.  It's not so easy to do that if you
are only dealing with the plugin binaries.

Thanks,
 Aaron


Re: [VOTE] Release Servicemix 3.0.1

2006-10-17 Thread Bruce Snyder

On 10/16/06, Guillaume Nodet [EMAIL PROTECTED] wrote:

I'd like to start the release process for 3.0.1.
The list of bugs fixed in 3.0.1 is available at
http://issues.apache.org/activemq/secure/IssueNavigator.jspa?view=decorator=printablestart=0fixfor=11716mode=hidereset=truepid=10950tempMax=1000

[ ] +1 Release servicemix 3.0.1
[ ] 0 Abstain
[ ] -1 Do not release servicemix 3.0.1

Here's my +1


+1

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


Re: Trying to use the new activemq-cpp makefiles, some issues remain for Solaris

2006-10-17 Thread Hiram Chirino

Hum.. looks like it still setup to do .so builds perhaps if I switch to
doing .a builds things will work better.  I'll look into this a little
later.

On 10/17/06, Bish, Tim [EMAIL PROTECTED] wrote:



Hiram.

I've been hacking away trying to get a build on Solaris 10 using the
newer automake stuff.  So far I've had some success but still can't
build the library.

There seems to be some issues with the way sun has set things up on the
sun box. I had to hack up a libstdc++.la as described in this article.
http://forum.sun.com/jive/thread.jspa?threadID=73150

I deleted the old makefiles so that gmake could find the Makefile
versions.

I end up with this error on attempting to build the find library file.

g++ -g -O2 -o .libs/example main.o  ../main/.libs/libactivemq-cpp.so
/usr/sfw/lib/libstdc++.so -lc -L/usr/sfw/lib -lm -lpthread -luuid -Wl,-R
-Wl,/usr/local/lib -Wl,-R -Wl,/usr/sfw/lib
ld: warning: file /usr/sfw/lib/libstdc++.so: attempted multiple
inclusion of file
Undefined   first referenced
symbol in file
nanosleep   ../main/.libs/libactivemq-cpp.so

I added an include of time.h to Thread.cpp which is the only code that
uses nanosleep, and that doesn't seem to help.  According to the man
nanosleep this is where it should come from on SUN.

When I try and use the Solaris Compiler I get really crazy errors that
don't seem to make any sense.

Everything builds fine using the older Makefiles, so I think that the
source code is okay.

Any ideas?





--
Regards,
Hiram

Blog: http://hiramchirino.com


RE: Openwire C++ client for AMQ

2006-10-17 Thread Timothy Bish
Yes, that folder contains the only cpp openwire client at the moment.

 -Original Message-
 From: Dhawan, Vikram (LNG-DAY) [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, October 17, 2006 5:30 PM
 To: activemq-dev@geronimo.apache.org
 Subject: Openwire C++ client for AMQ
 Importance: High
 
 I saw some discussion around Openwire C++ client is available now (with
 Queue's and Topic's support). I will appreciate if some one can tell me
 where to download it from?
 
 
 
 I was trying to find out on svn and there is a directory called
 openwire-cpp is this the directory for openwire-cpp client?
 
 
 
 Thanks!
 
 
 
 Vik
 
 




RE: Openwire C++ client for AMQ

2006-10-17 Thread Dhawan, Vikram \(LNG-DAY\)
Thanks Tim, 

And I assume this open wire client code is a tested :).

Thanks!

Vik

-Original Message-
From: Timothy Bish [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, October 17, 2006 5:43 PM
To: activemq-dev@geronimo.apache.org
Subject: RE: Openwire C++ client for AMQ

Yes, that folder contains the only cpp openwire client at the moment.

 -Original Message-
 From: Dhawan, Vikram (LNG-DAY) [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, October 17, 2006 5:30 PM
 To: activemq-dev@geronimo.apache.org
 Subject: Openwire C++ client for AMQ
 Importance: High
 
 I saw some discussion around Openwire C++ client is available now
(with
 Queue's and Topic's support). I will appreciate if some one can tell
me
 where to download it from?
 
 
 
 I was trying to find out on svn and there is a directory called
 openwire-cpp is this the directory for openwire-cpp client?
 
 
 
 Thanks!
 
 
 
 Vik
 
 


[jira] Created: (GERONIMO-2499) Generalize NamingBuilder so it can handle more than just jndi building

2006-10-17 Thread David Jencks (JIRA)
Generalize NamingBuilder so it can handle more than just jndi building
--

 Key: GERONIMO-2499
 URL: http://issues.apache.org/jira/browse/GERONIMO-2499
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: deployment
Affects Versions: 1.2
Reporter: David Jencks
 Assigned To: David Jencks
 Fix For: 1.2


we need a more unified idea of a deployer.  I think we might be able to 
generalize and abstract the NamingBuilder interface.  One needed step is to 
pass a map of info useful to the builders rather than just the jndi context 
map.  The jndi context map can be an entry in the new map.

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




[jira] Commented: (GERONIMO-2499) Generalize NamingBuilder so it can handle more than just jndi building

2006-10-17 Thread David Jencks (JIRA)
[ 
http://issues.apache.org/jira/browse/GERONIMO-2499?page=comments#action_12443131
 ] 

David Jencks commented on GERONIMO-2499:


rev 465110 changes the NamingBuilder usage to use the map parameter as a bucket 
rather than the jndi context map.

 Generalize NamingBuilder so it can handle more than just jndi building
 --

 Key: GERONIMO-2499
 URL: http://issues.apache.org/jira/browse/GERONIMO-2499
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: deployment
Affects Versions: 1.2
Reporter: David Jencks
 Assigned To: David Jencks
 Fix For: 1.2


 we need a more unified idea of a deployer.  I think we might be able to 
 generalize and abstract the NamingBuilder interface.  One needed step is to 
 pass a map of info useful to the builders rather than just the jndi context 
 map.  The jndi context map can be an entry in the new map.

-- 
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: Geronimo Liferay Plugins

2006-10-17 Thread Donald Woods

Option #1 is fine for the plug-in that supports Geronimo 1.1.1.
Maybe for the plugin that supports the required naming changes in the 
Geronimo 1.2 release, we can get Option #2 implemented.



Thanks,
Donald

Paul McMahan wrote:

Right, that's a better way of putting it -- thanks for the
clarification Aaron.  So to sum up, I think the two choices we've
discussed so far are:
1.)  add the www.ibiblio.org/maven2 repository to geronimo-plugins.xml
2.)  remove the Derby version number from the dependency element in
the connector's original deployment plan and then recreate the CAR
file.  One way to do that is to redeploy the modified connector into
geronimo and then export it as a plugin using the console. Then
replace the connector plugin in the repo and remove the Derby version
number from geronimo-plugins.xml.

Best wishes,
Paul

On 10/17/06, Aaron Mulder [EMAIL PROTECTED] wrote:


On 10/17/06, Paul McMahan [EMAIL PROTECTED] wrote:
 Otherwise, as Aaron said the modules should be reinstalled and
 re-exported as plugins alongside the changes you requested to the
 dependency metadata.

I was actually saying that whoever originally created the plugins (and
therefore has the Geronimo plans used to deploy the modules in the
first place) should update the dependency elements used in those
plans and recreate the CAR files.  It's not so easy to do that if you
are only dealing with the plugin binaries.

Thanks,
 Aaron





smime.p7s
Description: S/MIME Cryptographic Signature


Re: Binding into global (and other) jndi

2006-10-17 Thread David Jencks
FWIW I've removed the TSSBean reference from the ejb containers and  
made a TSSLink and TSSLinkBuilder that installs them as part of  
separating the corba related classes into a separate jar  
(OPENEJB-280).  The jndi names and local-jndi-names are unfortunately  
still attached to the ejb container.


thanks
david jencks

On Oct 1, 2006, at 11:16 AM, David Jencks wrote:

Dain has been working on a global jndi implementation that looks  
really nice.  However the deployment of bindings part of it has  
brought up some long-festering architectural worries and perhaps we  
are now in a position to deal with them in a systematic manner.


David Blevins pointed out to me a long time ago that one of the  
core principles of openejb was that ejb containers should have  
nothing transport specific attached to them.  This was when I  
installed a TSSBean reference in ejb containers to enable binding  
ejbs into corba.  I pointed out that letting the ejb container know  
jndi-names and local-jndi-names had the same problem, and IIRC he  
agreed that this was an architectural flaw.  In any case,  
intentionally or not, he convinced me that both the tssbean link  
and the jndi names should not be attached to the ejb container.  If  
you install dain's global jndi stuff the jndi names now get  
recycled up to 3 times: for the openejb proprietary jndi impl,  
global jndi, and corba.  The global jndi connector binding creates  
a similar but worse problem for j2ca connectors, since it tries to  
bind using only the name component of the abstract name, rather  
than allowing a specific global jndi name, and AFAICT it doesn't  
let you specify which connectors you want to bind.


I think for all of these situations a cleaner runtime solution is a  
component that links the thing you want to bind and the binding  
context, and includes the name(s) you want to bind under.   
Currently this would I think have to be a gbean.  This is what Dain  
implemented for gbean bindings.  So, I'm proposing that bindings  
for connectors in global jndi, and ejbs in global jndi, corba, and  
the openejb jndi, each be set up by gbeans, each holding the name 
(s) to bind under and a reference to the object to be bound.  This  
part is pretty easy to write.


Slightly harder is deployment: setting up these gbeans.  If we  
modify our schemas this can be done using NamingBuilders: here they  
won't be constructing the components jndi context but rather  
exposing the component in various naming systems. I think the  
really hard part is figuring out some xml that is manageable to  
write and expresses the meaning clearly.


For connectors it's pretty easy, we can just have a repeating element
global-jndi-namefoo/global-jndi-name

For ejbs with the current 3 naming systems it's a bit harder.  One  
possibility would look something like this:


jndi
  global/
  corba
 tss-linkfoo-tss/tss-link
  /corba
  openejb/
  remote-namefoo/remote-name
  local-namebar/local-name
/jndi

where the global, corba, and openejb elements indicate which naming  
system to bind to and the names are supplied with remote-name and  
local-name.  A remote jndi would ignore the local-name elements.   
You could have multiple jndi elements to get different bindings in  
different naming systems.


To make this extensible the naming system elements would have to be  
in a substitution group and extend an abstract element.  The ones  
we know about now could all be in the same namespace.



Thoughts?

thanks
david jencks





Atlanta JUG

2006-10-17 Thread Matt Hogstrom
I had the opportunity to speak to some folks at the Atlanta JUG  
tonight and thought I'd share the feedback.


First off, the JUG was held at the Atlanta Holiday Inn and was  
located in two adjacent rooms.  I can't recall the exact number but I  
think there were about 60 people in attendance.  It was one of the  
better organized JUG's I've had the opportunity to attend.  Burr  
Sutter was an excellent host and did a great job pulling the event  
together.


There were a few folks who figured this was JBoss country and that it  
might be a dangerous trip :)  I'm happy to report there were  
several JBoss employees at the JUG but they were very welcoming and  
we had a great chat after the event.  It was interesting swapping  
stories about Open Source and comparing and contrasting the JBoss  
model versus Apache.  I really enjoyed it.


All in all people were really interested in Geronimo and had most of  
their experience on JBoss.  They liked the modular architecture and  
some of the things that were coming in 1.2 (caching, 1.5 support, and  
possible OpenJPA).  They also liked the Yoko option to give  
flexibility in changing VMs.  I was surprised that many of the folks  
used CORBA and this was an important function for them.  I was also  
surprised when several of the folks indicated that they used EJBs and  
XA 2-phase commit.  I told them about D Jencks Tx Manager and told  
them I'd relay their level of interest.


There were several people that were interested in JEE 5 support and I  
told them that D Blevins and folks were working away and we'd like to  
get something in their hands sooner than later.


There was also a short discussion about why GBeans (from one of the  
JBoss guys) and we talked about the progression of GBeans and pointed  
them to the dev list and Dain for the more detailed discussion.  They  
seemed to understand our additional requirements and the conversation  
was again really productive.


Someone came up to me and mentioned that Intalio was shipping  
Geronimo and using it.  I didn't know this.


All in all it was a great meeting and in Atlanta people are waiting  
to see great things from Geronimo.  Just thought I'd provide the  
feedback.


Cheers.

Matt Hogstrom
[EMAIL PROTECTED]





Re: Atlanta JUG

2006-10-17 Thread Jeff Genender
Awesome!  Sounds like a great meeting and presentation!

Jeff

Matt Hogstrom wrote:
 I had the opportunity to speak to some folks at the Atlanta JUG tonight
 and thought I'd share the feedback.
 
 First off, the JUG was held at the Atlanta Holiday Inn and was located
 in two adjacent rooms.  I can't recall the exact number but I think
 there were about 60 people in attendance.  It was one of the better
 organized JUG's I've had the opportunity to attend.  Burr Sutter was an
 excellent host and did a great job pulling the event together.
 
 There were a few folks who figured this was JBoss country and that it
 might be a dangerous trip :)  I'm happy to report there were several
 JBoss employees at the JUG but they were very welcoming and we had a
 great chat after the event.  It was interesting swapping stories about
 Open Source and comparing and contrasting the JBoss model versus
 Apache.  I really enjoyed it.
 
 All in all people were really interested in Geronimo and had most of
 their experience on JBoss.  They liked the modular architecture and some
 of the things that were coming in 1.2 (caching, 1.5 support, and
 possible OpenJPA).  They also liked the Yoko option to give flexibility
 in changing VMs.  I was surprised that many of the folks used CORBA and
 this was an important function for them.  I was also surprised when
 several of the folks indicated that they used EJBs and XA 2-phase
 commit.  I told them about D Jencks Tx Manager and told them I'd relay
 their level of interest.
 
 There were several people that were interested in JEE 5 support and I
 told them that D Blevins and folks were working away and we'd like to
 get something in their hands sooner than later.
 
 There was also a short discussion about why GBeans (from one of the
 JBoss guys) and we talked about the progression of GBeans and pointed
 them to the dev list and Dain for the more detailed discussion.  They
 seemed to understand our additional requirements and the conversation
 was again really productive.
 
 Someone came up to me and mentioned that Intalio was shipping Geronimo
 and using it.  I didn't know this.
 
 All in all it was a great meeting and in Atlanta people are waiting to
 see great things from Geronimo.  Just thought I'd provide the feedback.
 
 Cheers.
 
 Matt Hogstrom
 [EMAIL PROTECTED]
 
 


Re: Daytrader deployment plans?

2006-10-17 Thread Matt Hogstrom
Trunk needs to be cleaned up.  thanks for the ping.  DayTrader used to get built as part of Geronimo.  I have been removing it.  There was a bit of a shuffle with trunk earlier this year based on a huge set of work Dain and Djencks did.  I have some outstanding commits left to reapply to trunk.  So for now, use the plans in 1.1.  OpenEJB also changed recently as its moving to Apache and the plans need to be updated to org.apache.openejb from org.openejbOn Oct 17, 2006, at 2:50 PM, Christopher Blythe wrote:All...I'm a little confused about the Daytrader deployment plans riddled throughout the source tree and was wondering if someone could clear up my confusion?Under the tags/1.1.0 and branches/1.1 source trees, the tomcat-plan.xml and jetty-plan.xml are located and I have been using these on Geronimo 1.1 without a problem.However, if I look under trunk, these files are no where to be found. Instead, it still looks like the old 1.0 deployment plans are located there.Can anyone clarify?Thanks...Chris Matt Hogstrom[EMAIL PROTECTED]