date:20061016


On 10/14/06, Brian Chan [EMAIL PROTECTED] 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

Re: Geronimo Liferay Plugins



Jacek Laskowski wrote:
 On 10/14/06, Brian Chan [EMAIL PROTECTED] 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.

geronimoplugins.com is the same, so we should probably be consistent.

 
 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

Re: Geronimo Liferay Plugins


On 10/16/06, Jeff Genender [EMAIL PROTECTED] wrote:


geronimoplugins.com is the same, so we should probably be consistent.


Would you explain (possibly again) why it is configured this way?

Jacek

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

Re: Geronimo Liferay Plugins



Jacek Laskowski wrote:
 On 10/16/06, Jeff Genender [EMAIL PROTECTED] wrote:
 
 geronimoplugins.com is the same, so we should probably be consistent.
 
 Would you explain (possibly again) why it is configured this way?

I am actually in agreement with you.  I don't really know why it's
configured this way.  My point was that if we need to have Liferay open
up directory viewing, then so should everyone else.  What's good for the
goose is good for the gander ;-)

IMHO, I think it probably should be up to the contributing organization
if they want their directories viewable...I don't think that needs to be
a requirement.  Since all we care about is the plugins, we just need to
look at the top level geronimo-plugins.xml and it will basically tell
you what is available in their directory structure.

 
 Jacek

Re: Geronimo Liferay Plugins


On 10/16/06, Jeff Genender [EMAIL PROTECTED] wrote:


IMHO, I think it probably should be up to the contributing organization
if they want their directories viewable...I don't think that needs to be
a requirement.  Since all we care about is the plugins, we just need to
look at the top level geronimo-plugins.xml and it will basically tell
you what is available in their directory structure.


Agreed. It should be added to plugin documentation somewhere. Will
take care of it later if noone beats me to it ;-)

Thanks!

Jacek

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

Re: gcache imlementation ideas[long]

2006-10-16 Thread Gianny Damour


Hi,

I think such an API will start to be useful for people interested to  
implement distributed or clustered services. At this stage, there is  
not a real need for such a capability; so, this may be a little bit  
premature to introduce it.


After some experiments with an API similar to the proposed one, I  
have reached the conclusion that the methods Node.getNodeAttributes  
and NodeListener.onNodeChange are not so great. Basically, you do not  
know which attributes have been changed and when they are propagated.  
So, if you had to write two services relying on nodeAttributes to  
exchange information, then the only way that I have been able to make  
such a thing work is to: timestamp each Map entry; check the  
existence of the entry you are interested in to filter out the  
irrelevant nodeChange events; store somewhere the timestamp of the  
last processed entry; and compare the timestamp of the Map entry with  
the one of the last processed entry. There are more elegant  
solutions; yet they require custom code on top of the API, which  
should simplify developers' life.


Thanks,
Gianny

On 12/10/2006, at 7:44 AM, Filip Hanik - Dev Lists wrote:



I addressed the discussion about what transport do we use, a long  
time ago by creating an agnostic API to plug into.

http://marc.theaimsgroup.com/?l=geronimo-devm=115281186718399w=2
http://people.apache.org/~fhanik/geronimo-cluster-api.zip

this way, we can continue the pluggability of G, and not pushing  
any specific protocols.
but writing a custom one just for G doesn't sound like a sound  
solution


in addition to ehcache, I'd like to propose that we take a look at  
ASF's JCS(Java Cache System) which sits under the Jakarta umbrella.

http://jakarta.apache.org/jcs/index.html

and a performance report http://jakarta.apache.org/jcs/ 
JCSvsEHCache.html (could be outdated)


sorry about splitting up the gcache discussion, actually it was  
already split when we started talking about the transport a while  
back in this thread.
However, my take on it is that we should use code already written,  
while this is all really cool stuff to work on, creating a  
distributed cache from start is hard and takes a very long time. I  
would think the main goal is to get to JEE 5 right now.



Filip

Re: Geronimo Liferay Plugins

2006-10-16 Thread Aaron Mulder


On 10/14/06, Brian Chan [EMAIL PROTECTED] wrote:

The latest Liferay portal plugins are now available on.

http://geronimo.liferay.com/plugins


Nice!


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


We can actually add it for 1.1.1 if you like -- according to the
plugin metadata, this same plugin works in both 1.1.1 and
1.2-SNAPSHOT.  Is that right; has it been tested in both?


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.


Great!

Thanks,
 Aaron

Re: Geronimo Liferay Plugins

2006-10-16 Thread Paul McMahan


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

On 10/14/06, Brian Chan [EMAIL PROTECTED] wrote:
 The latest Liferay portal plugins are now available on.

 http://geronimo.liferay.com/plugins

Nice!

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

We can actually add it for 1.1.1 if you like -- according to the
plugin metadata, this same plugin works in both 1.1.1 and
1.2-SNAPSHOT.  Is that right; has it been tested in both?


The plugins work fine for me in Geronimo 1.1.1.  I agree it would be a
great idea to add this repo to the default repository list for 1.1.1.
However, in Geronimo 1.2 our group id changed from geronimo to
org.apache.geronimo so we'll need new versions of the plugins that
reference the Geronimo prerequisites correctly for that release.  I
can offer my assistance to Liferay on creating them.  IIUC the
tentative plan is to release Geronimo 1.2 towards the end of this
year, so we should coordinate things around that timeframe.

Also, I worked on a Jetty version of the plugin but encountered some
problems with classloading that I think may be due to the Jetty
assembly pulling in Spring and/or cglib differently than the Tomcat
assembly?  I saw a couple of emails go by last week about issues with
Spring in the Jetty assembly, perhaps that could be related.  I
haven't drilled down far enough to know the real culprit yet.

Best wishes,
Paul

Patches in RTC (Geronimo - 2006-10-16)

2006-10-16 Thread dblevins

Geronimo - Monday, October 16, 2006

  4 Patches in RTC

[GERONIMO-2485] PersistenceUnitGBean needs a NamespaceDrivenDeployer
  - Assignee: David Jencks
  - Reporter: David Jencks
  - Created:  Wed Oct 11 14:23:29 PDT 2006
  - Updated:  Wed Oct 11 19:09:21 PDT 2006
  - Votes: 0
  - http://issues.apache.org/jira/browse/GERONIMO-2485

[GERONIMO-1277] Change group-id to org.apache.geronimo
  - Assignee: Jason Dillon
  - Reporter: Dain Sundstrom
  - Created:  Sat Dec 03 02:55:12 PST 2005
  - Updated:  Sun Oct 01 15:38:21 PDT 2006
  - Votes: 1
  1  David Jencks
  - http://issues.apache.org/jira/browse/GERONIMO-1277

[GERONIMO-2015] Let's replace JKS to PKCS12 key store type
  - Assignee: Unassigned
  - Reporter: Nikolay Chugunov
  - Created:  Fri May 12 14:54:17 PDT 2006
  - Updated:  Fri Oct 13 07:57:40 PDT 2006
  - Votes: 0
  - http://issues.apache.org/jira/browse/GERONIMO-2015

[GERONIMO-2409] Provide config/module aliasing ability
  - Assignee: David Jencks
  - Reporter: David Jencks
  - Created:  Fri Sep 15 15:36:59 PDT 2006
  - Updated:  Mon Sep 25 10:14:18 PDT 2006
  - Votes: 3
  1  Gianny Damour
  2  Jeff Genender
  3  Joe Bohn
  - http://issues.apache.org/jira/browse/GERONIMO-2409


NOTE: This email is generated and does not constitute and offical
vote or vote result.  All official voting is done on the dev list.

If you do not see your issue here, click the Begin RTC Review
link under the Available Workflow Actions of the JIRA page.

If you do not see your vote here, click the Vote link under the
Operations section of the JIRA page.


 *** ALL COMMUNITY MEMBERS ARE ENCOURAGED TO VOTE ***

Template: 
http://svn.apache.org/repos/asf/geronimo/gbuild/jirareports/patchesInRtc.vm

[jira] Assigned: (GERONIMODEVTOOLS-110) Exception in IModulePublishHelper.getPublishDirectory() for Geronimo

2006-10-16 Thread Sachin Patel (JIRA)

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

Sachin Patel reassigned GERONIMODEVTOOLS-110:
-

Assignee: Sachin Patel

 Exception in IModulePublishHelper.getPublishDirectory() for Geronimo
 

 Key: GERONIMODEVTOOLS-110
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-110
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 1.x
 Environment: Windows XP
Reporter: Kathy Chan
 Assigned To: Sachin Patel
Priority: Critical

 Driver:  Geronimo 1.1 unreleased driver g-eclipse-plugin-20060926-2.zip from:
 http://people.apache.org/dist/geronimo/eclipse/unstable/
 On WTP 1.5.1 09/22 0504 driver using Geronimo 1.1.1 Tomcat server.
 When creating a Web service on g3EAR containing the g3 Web module, we need to 
 call IModulePublishHelper.getPublishDirectory(), here's the resulting 
 exception:
 org.apache.geronimo.kernel.InternalKernelException: 
 java.rmi.UnmarshalException: error unmarshalling return; nested exception is: 
   java.io.IOException: Unable to deserialize GBeanData 
 default/g3EAR/1.0/car?configurationName=default/g3EAR/1.0/car
   at 
 org.apache.geronimo.system.jmx.KernelDelegate.getGBeanData(KernelDelegate.java:762)
   at 
 org.apache.geronimo.st.v11.core.GeronimoServerBehaviour.getPublishDirectory(GeronimoServerBehaviour.java:179)
   at 
 org.eclipse.jst.ws.internal.axis.creation.ui.command.CopyDeploymentFileCommand.execute(CopyDeploymentFileCommand.java:99)
   at 
 org.eclipse.wst.command.internal.env.core.fragment.CommandFragmentEngine.runCommand(CommandFragmentEngine.java:413)
   at 
 org.eclipse.wst.command.internal.env.core.fragment.CommandFragmentEngine.visitTop(CommandFragmentEngine.java:353)
   at 
 org.eclipse.wst.command.internal.env.core.fragment.CommandFragmentEngine.moveForwardToNextStop(CommandFragmentEngine.java:251)
   at 
 org.eclipse.wst.command.internal.env.ui.widgets.SimpleCommandEngineManager$5.run(SimpleCommandEngineManager.java:250)
   at 
 org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:369)
   at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:313)
   at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java:851)
   at 
 org.eclipse.wst.command.internal.env.ui.widgets.SimpleCommandEngineManager.runForwardToNextStop(SimpleCommandEngineManager.java:220)
   at 
 org.eclipse.wst.command.internal.env.ui.widgets.WizardPageManager.runForwardToNextStop(WizardPageManager.java:94)
   at 
 org.eclipse.wst.command.internal.env.ui.widgets.WizardPageManager.performFinish(WizardPageManager.java:250)
   at 
 org.eclipse.wst.command.internal.env.ui.widgets.DynamicWizard.performFinish(DynamicWizard.java:332)
   at 
 org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDialog.java:680)
   at 
 org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java:355)
   at org.eclipse.jface.dialogs.Dialog$3.widgetSelected(Dialog.java:660)
   at 
 org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:90)
   at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
   at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928)
   at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348)
   at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2968)
   at org.eclipse.jface.window.Window.runEventLoop(Window.java:820)
   at org.eclipse.jface.window.Window.open(Window.java:796)
   at 
 org.eclipse.wst.command.internal.env.ui.widgets.popup.DynamicPopupWizard.run(DynamicPopupWizard.java:130)
   at 
 org.eclipse.ui.internal.PluginAction.runWithEvent(PluginAction.java:254)
   at 
 org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:539)
   at 
 org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:488)
   at 
 org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:400)
   at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
   at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928)
   at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348)
   at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2968)
   at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914)
   at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878)
   at 
 org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:419)
   at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
   at 
 org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:95)
   at

Re: Geronimo Liferay Plugins



Paul McMahan wrote:
 Also, I worked on a Jetty version of the plugin but encountered some
 problems with classloading that I think may be due to the Jetty
 assembly pulling in Spring and/or cglib differently than the Tomcat
 assembly?  I saw a couple of emails go by last week about issues with
 Spring in the Jetty assembly, perhaps that could be related.  I
 haven't drilled down far enough to know the real culprit yet.

I suspect a hidden-classes declaration in the Liferay environment will
fix this for you.

 
 Best wishes,
 Paul

[jira] Closed: (GERONIMODEVTOOLS-110) Exception in IModulePublishHelper.getPublishDirectory() for Geronimo

2006-10-16 Thread Sachin Patel (JIRA)

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

Sachin Patel closed GERONIMODEVTOOLS-110.
-

Fix Version/s: 1.x
   Resolution: Fixed

 Exception in IModulePublishHelper.getPublishDirectory() for Geronimo
 

 Key: GERONIMODEVTOOLS-110
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-110
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 1.x
 Environment: Windows XP
Reporter: Kathy Chan
 Assigned To: Sachin Patel
Priority: Critical
 Fix For: 1.x


 Driver:  Geronimo 1.1 unreleased driver g-eclipse-plugin-20060926-2.zip from:
 http://people.apache.org/dist/geronimo/eclipse/unstable/
 On WTP 1.5.1 09/22 0504 driver using Geronimo 1.1.1 Tomcat server.
 When creating a Web service on g3EAR containing the g3 Web module, we need to 
 call IModulePublishHelper.getPublishDirectory(), here's the resulting 
 exception:
 org.apache.geronimo.kernel.InternalKernelException: 
 java.rmi.UnmarshalException: error unmarshalling return; nested exception is: 
   java.io.IOException: Unable to deserialize GBeanData 
 default/g3EAR/1.0/car?configurationName=default/g3EAR/1.0/car
   at 
 org.apache.geronimo.system.jmx.KernelDelegate.getGBeanData(KernelDelegate.java:762)
   at 
 org.apache.geronimo.st.v11.core.GeronimoServerBehaviour.getPublishDirectory(GeronimoServerBehaviour.java:179)
   at 
 org.eclipse.jst.ws.internal.axis.creation.ui.command.CopyDeploymentFileCommand.execute(CopyDeploymentFileCommand.java:99)
   at 
 org.eclipse.wst.command.internal.env.core.fragment.CommandFragmentEngine.runCommand(CommandFragmentEngine.java:413)
   at 
 org.eclipse.wst.command.internal.env.core.fragment.CommandFragmentEngine.visitTop(CommandFragmentEngine.java:353)
   at 
 org.eclipse.wst.command.internal.env.core.fragment.CommandFragmentEngine.moveForwardToNextStop(CommandFragmentEngine.java:251)
   at 
 org.eclipse.wst.command.internal.env.ui.widgets.SimpleCommandEngineManager$5.run(SimpleCommandEngineManager.java:250)
   at 
 org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:369)
   at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:313)
   at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java:851)
   at 
 org.eclipse.wst.command.internal.env.ui.widgets.SimpleCommandEngineManager.runForwardToNextStop(SimpleCommandEngineManager.java:220)
   at 
 org.eclipse.wst.command.internal.env.ui.widgets.WizardPageManager.runForwardToNextStop(WizardPageManager.java:94)
   at 
 org.eclipse.wst.command.internal.env.ui.widgets.WizardPageManager.performFinish(WizardPageManager.java:250)
   at 
 org.eclipse.wst.command.internal.env.ui.widgets.DynamicWizard.performFinish(DynamicWizard.java:332)
   at 
 org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDialog.java:680)
   at 
 org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java:355)
   at org.eclipse.jface.dialogs.Dialog$3.widgetSelected(Dialog.java:660)
   at 
 org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:90)
   at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
   at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928)
   at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348)
   at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2968)
   at org.eclipse.jface.window.Window.runEventLoop(Window.java:820)
   at org.eclipse.jface.window.Window.open(Window.java:796)
   at 
 org.eclipse.wst.command.internal.env.ui.widgets.popup.DynamicPopupWizard.run(DynamicPopupWizard.java:130)
   at 
 org.eclipse.ui.internal.PluginAction.runWithEvent(PluginAction.java:254)
   at 
 org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:539)
   at 
 org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:488)
   at 
 org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:400)
   at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
   at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928)
   at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348)
   at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2968)
   at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914)
   at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878)
   at 
 org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:419)
   at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
   at

RE: Maven's snapshot mechanism is horked (Re: Build error - Is it from svn commit: r463555 - /geronimo/genesis/trunk/config/project-config/pom.xml?)

2006-10-16 Thread Jörg Schaible

Hi Jason,

download of SNAPSHOT dependencies does not work at all in M2.0.4:
http://jira.codehaus.org/browse/MNG-1908

- Jörg

Jason Dillon wrote on Saturday, October 14, 2006 10:17 PM:

 On Oct 14, 2006, at 6:58 AM, Kenney Westerhof wrote:
 Running mvn with -U -cpu should fix that (or wait 24 hours and try
 again :)).
 
 I don't think this helps... at least not the wait 24 hours.
 I was up
 late and was running a build at 11:50pm and it ran fine, then ran a
 build at 12:02am and it puked about missing versions from
 genesis 1.1-
 SNAPSHOT versions... which I had versions in my local repo that were
 all newer than any snap that I had deployed and I am the
 only one
 who deploys them, so no chance that it as deployed by someone else.
 
 The only way I could fix was to build genesis locally after the
 failed 12:02am build.  But the crazy part was that I had just done
 that at about 11:40pm, did *not deploy* so my local copy was newer,
 but maven decided not to resolve to those versions?!?!
 
 I don't think using `mvn -U` helps either, as that negates
 the use of
 caching SNAPSHOTs and will slowdown the build way to much.
 
 
 Another solution is to delete the metadata file from the local
 repository.
 
 Nope... this does not work either as the problem shows up
 quite often
 when you removed you local repo and build... ie... no local metadata
 at all.  So I don't think the problem is there.
 
 If there is a problem with the local metadata it is getting
 corrupted
 while mvn is running, so even removing the local repo cache will not
 ensure that the run will succeed.
 
 
 Btw, how come the original snapshot versions are removed from the
 remote repository? The local metadata file probably contains a
 reference to the old snapshot version, but doesn't seem to have it
 locally, which needs investigation.. 
 
 Who said anything about removing anything?  The genesis
 1.1-SNAPSHOTS
 have not been altered ore removed from the remote repo. In the
 specific problem build 1 - 23 of plugin-support are all available.
 
 
 As for the other snapshot errors: Maven 1 legacy repositories don't
 contain metadata files. Updating snapshots from them doesn't seem
 to work. That's another thing that
 should be investigated.
 
 I personally never have problems with snapshot versions, so maybe
 the use of maven 1 repositories
 and the removal of snapshots from the remote repository isn't
 handled correctly by Maven.
 
 I know there are issues with m1 repos... not specific to
 snapshots...
 though unfortunately we can not eliminate them completely from out
 build because we have a few dependencies which define m1 repos in
 their poms. 
 
 But... I think that use of m1 repos is only one of the
 problems going
 on here... something else, which I have yet to understand, is broken.
 
 One thing does look very fishy to me though
 
 snip
 1) org.apache.geronimo.genesis.plugins:plugin-support:jar:1.1-SNAPSHOT
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -
 DgroupId=org.apache.geronimo.genesis.plugins -DartifactId=plugin-
support \ -Dversion=1.1-20061013.014841-21 -Dpackaging=jar
-Dfile=/ path/to/file Path to dependency:
  1) org.apache.geronimo.genesis.plugins:tools-maven-
 plugin:maven-plugin:1.1-20061013.014841-21 2)
 org.apache.geronimo.genesis.plugins:plugin-support:jar:
 1.1-20061013.014841-21 --
 1 required artifact is missing.
 for artifact:
 org.apache.geronimo.genesis.plugins:tools-maven-plugin:maven-plugin:
 1.1-20061013.014841-21 from the specified
 /snip
 
 Notice that the tools-maven-plugin's timestamp-build is
 20061013.014841-21 and this is also the same timestamp-build that
 is being used for the plugin-support jar.  However the real
 timestamp
 for build 21 of plugins-support is 20061012.062745.
 
 --jason
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: DayTrader with an AJAX based Web interface

2006-10-16 Thread Christopher Blythe

Any initial thoughts on how we should start integrating this into the source tree?As I mentioned previously, I currently have the dojo interface module and web services proxy module in individual wars packaged in a separate ear. Do we want to keep this deployment model?
Or would it make more sense to package the wars directly in the trade ear?Thoughts or opinions?Thanks...ChrisOn 10/13/06,
Slava McDougald [EMAIL PROTECTED] wrote:
Hi Chris,The new Daytrader AJAX interface is much richer and user friendly thanthe WEB1.0.I love it.Very nice job!I tested it with both Firefox and IE.Impressively enough, it workedlike a charm, even with IE.
The only little glitch I noticed was the time, it took to load theDojo libraries into the browser when you first invoke the application. On my system it took about 10 sec.However, I did see a loading… alert during that time so I assume, it is ok.
But it would be nice if we can find some way to reduce the loading… time.SlavaOn 10/12/06, J. Stan Cox [EMAIL PROTECTED] wrote: When I first loaded the initial page, it didn't look right in FireFox
(text jumbled up a bit, etc.).However, I clicked refresh and it resolved the problem. After that, everything works perfectly.The interface is really cool. I'd like to see that patch get in soon, so the Geronimo world can
contribute. Stan. Paul McMahan wrote: On 10/12/06, Christopher Blythe [EMAIL PROTECTED] wrote: Paul...
Just read through the chain and the idea is sound... I like the idea of having a base dojo library accessible within the server, thus removing the burden on the developer of maintaining the dojo libraries within
their code. Yes that's the idea, plus (hopefully) there is some performance improvement via browser caching when multiple apps share the same library.
Plus, I don' t think there would be any conflicts if someone chose to do that in order to use newer builds of dojo, etc. My initial thinking on that has been that if an app needs a specific
newer or older build of dojo then they could still include it in their war. Or they could deploy a new shared version at a different context, say /dojo-verX.Y.Z/dojo.js, but that could quickly get unmanageable..
The server's version of dojo would still be deployed at /dojo and support applications that are not as sensitive to version changes (see below). Just curious, would it be
permissible for a developer to upgrade the dojo library inside the appserver on their own? Yes I think so,in the same way that an application might want to
upgrade any other library in the server, say tranql for instance.Of course other applications and native components in the server that were using the old version would automatically start using the new
version, so some care must be taken. Something else I just thought of... I wonder if there would be any impact on custom dojo widgets created by the developer. This is
actually what I have done with the DayTrader interface. May be worth trying out... Ideally custom widgets could be contributed back to the Dojo
foundation and show up in a later standard build of the library that gets incorporated into geronimo.But that's of course not always possible due to time constraints as well as there being cases where
the custom widgets are not appropriately licensed for dojo or not reusable in a highly generalized kind of way.It would be interesting to find out if one could include customized widgets from their
application's context while still using the shared library for the standard components.I think its possible by overriding certain parts of dojo's packaging mechanism but haven't tried it.
Your idea for serving up customized builds sounds interesting; however, I'm not sure if there is currently a way to accurately detect all of the libraries that are used by an application. Based on my experience, you
manually put together the list of libraries required for your build and then kick off ant. Let me poke around further and see what I can find out... If you pick up dojo from svn then they provide some build profiles
that I think could be used for this purpose. http://svn.dojotoolkit.org/dojo/trunk/buildscripts/profiles/There's a thread on this titled dojo in Geronimo (long) where this is being
discussed. Best wishes, Paul

Re: Release of Activemq 4.0.2


We've been trying to get the 4.0.2 release out the door for a while
now - the code has been done for a few weeks, we keep hitting issues
in source code formatting, missing license files or NOTICE files etc.
It should be done soon I hope

On 10/13/06, Christopher_Ong [EMAIL PROTECTED] wrote:


May I know when is the projected official release of Activemq 4.0.2 (because
I prefer it's feature of auto remove of expired message where 4.0.1 can't do
that)? Thanks
--
View this message in context: 
http://www.nabble.com/Release-of-Activemq-4.0.2-tf2435693.html#a6791875
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.





--

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

Re: Supporting any type of command over the ActiveMQ Transports


Sounds good to me!

On 10/13/06, Hiram Chirino [EMAIL PROTECTED] wrote:

Howdy folks.  I'm planning on committing a change to the Transport Interface
soon.

Basically I'm abstracting them a little more so that the transport any old
Object.  That way the transport layer does not constrain you to extending
from Command and Response.  I've started working on supporting the qpid
command set and abstracting this out a little will help me tremendously!

see: http://issues.apache.org/activemq/browse/AMQ-976

Please let me know if you think of an issue with this!
--
Regards,
Hiram

Blog: http://hiramchirino.com





--

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

Re: Geronimo Liferay Plugins

2006-10-16 Thread Paul McMahan


On 10/16/06, Jeff Genender [EMAIL PROTECTED] wrote:



Paul McMahan wrote:
 Also, I worked on a Jetty version of the plugin but encountered some
 problems with classloading that I think may be due to the Jetty
 assembly pulling in Spring and/or cglib differently than the Tomcat
 assembly?  I saw a couple of emails go by last week about issues with
 Spring in the Jetty assembly, perhaps that could be related.  I
 haven't drilled down far enough to know the real culprit yet.

I suspect a hidden-classes declaration in the Liferay environment will
fix this for you.


I suspected that at first and added this to geronimo-application.xml :
hidden-classes
   filterorg.springframework/filter
/hidden-classes

But I still get the ST at the bottom of this note, the following
portion looking especially suspect:
 interface org.springframework.aop.framework.Advised is not visible
from class loader

I've tried several other different variations of using
hidden-classes, non-overrideable-classes, and dependency to work
around this.   But without a thorough understanding of the underlying
problem I'm starting to feel like I'm taking shots in the dark.
Unless there's enough information in the ST below to trigger some
suggestions I suppose I just need to bite the bullet and crawl through
startup with a debugger :-)

BTW, the magic ingredient that worked for me in creating the 4.0.0
Liferay plugin for Geronimo's 1.1 tomcat assembly was:
hidden-classes
   filterorg.apache.commons.logging/filter
   filterorg.apache.velocity/filter
   filterorg.springframework/filter
   /hidden-classes
non-overridable-classes
   filternet.sf.cglib/filter
   /non-overridable-classes
This forced Geronimo to use Spring from Liferay but cglib from
Geronimo.  But now the tomcat liferay plugin doesn't need this and the
same plan doesn't work for Jetty.

com.liferay.portal.SystemException:
org.springframework.beans.factory.BeanCreationException: Error
creating bean with name
'com.liferay.lock.service.spring.LockServiceFactory' defined in class
path resource [META-INF/lock-spring-enterprise.xml]: Cannot resolve
reference to bean
'com.liferay.lock.service.spring.LockService.enterprise' while setting
bean property 'service'; nested exception is
org.springframework.beans.factory.BeanCreationException: Error
creating bean with name
'com.liferay.lock.service.spring.LockService.enterprise' defined in
class path resource [META-INF/lock-spring-enterprise.xml]:
Initialization of bean failed; nested exception is
java.lang.IllegalArgumentException: interface
org.springframework.aop.framework.Advised is not visible from class
loader
   at 
com.liferay.lock.service.spring.LockServiceUtil.clear(LockServiceUtil.java:48)
   at com.liferay.portal.events.StartupAction.run(StartupAction.java:66)
   at 
com.liferay.portal.events.EventsProcessor._process(EventsProcessor.java:144)
   at 
com.liferay.portal.events.EventsProcessor.process(EventsProcessor.java:73)
   at com.liferay.portal.servlet.MainServlet.init(MainServlet.java:135)
   at javax.servlet.GenericServlet.init(GenericServlet.java:168)
   at 
org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:383)
   at org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:243)
   at 
org.apache.geronimo.jetty.JettyWebAppContext.registerServletHolder(JettyWebAppContext.java:588)
   at 
org.apache.geronimo.jetty.JettyWebAppContext$$FastClassByCGLIB$$99d6fb54.invoke(generated)
   at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
   at 
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
   at 
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
   at 
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
   at 
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
   at 
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
   at 
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
   at 
org.apache.geronimo.management.geronimo.WebModule$$EnhancerByCGLIB$$7577bc9a.registerServletHolder(generated)
   at 
org.apache.geronimo.jetty.JettyServletHolder.init(JettyServletHolder.java:80)
   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
   at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
   at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
   at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
   at 
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:933)
   at

Re: Geronimo Liferay Plugins

Paul,

I had the same problem in Tomcat too until I pulled the
org.springframework filter from the container level deployer.  That is
very likely the problem you are running into.  Remove the filter from
jetty-deployer and I suspect this will fix your problem.

Jeff

Paul McMahan wrote:
 On 10/16/06, Jeff Genender [EMAIL PROTECTED] wrote:


 Paul McMahan wrote:
  Also, I worked on a Jetty version of the plugin but encountered some
  problems with classloading that I think may be due to the Jetty
  assembly pulling in Spring and/or cglib differently than the Tomcat
  assembly?  I saw a couple of emails go by last week about issues with
  Spring in the Jetty assembly, perhaps that could be related.  I
  haven't drilled down far enough to know the real culprit yet.

 I suspect a hidden-classes declaration in the Liferay environment will
 fix this for you.
 
 I suspected that at first and added this to geronimo-application.xml :
 hidden-classes
filterorg.springframework/filter
 /hidden-classes
 
 But I still get the ST at the bottom of this note, the following
 portion looking especially suspect:
  interface org.springframework.aop.framework.Advised is not visible
 from class loader
 
 I've tried several other different variations of using
 hidden-classes, non-overrideable-classes, and dependency to work
 around this.   But without a thorough understanding of the underlying
 problem I'm starting to feel like I'm taking shots in the dark.
 Unless there's enough information in the ST below to trigger some
 suggestions I suppose I just need to bite the bullet and crawl through
 startup with a debugger :-)
 
 BTW, the magic ingredient that worked for me in creating the 4.0.0
 Liferay plugin for Geronimo's 1.1 tomcat assembly was:
 hidden-classes
filterorg.apache.commons.logging/filter
filterorg.apache.velocity/filter
filterorg.springframework/filter
/hidden-classes
 non-overridable-classes
filternet.sf.cglib/filter
/non-overridable-classes
 This forced Geronimo to use Spring from Liferay but cglib from
 Geronimo.  But now the tomcat liferay plugin doesn't need this and the
 same plan doesn't work for Jetty.
 
 com.liferay.portal.SystemException:
 org.springframework.beans.factory.BeanCreationException: Error
 creating bean with name
 'com.liferay.lock.service.spring.LockServiceFactory' defined in class
 path resource [META-INF/lock-spring-enterprise.xml]: Cannot resolve
 reference to bean
 'com.liferay.lock.service.spring.LockService.enterprise' while setting
 bean property 'service'; nested exception is
 org.springframework.beans.factory.BeanCreationException: Error
 creating bean with name
 'com.liferay.lock.service.spring.LockService.enterprise' defined in
 class path resource [META-INF/lock-spring-enterprise.xml]:
 Initialization of bean failed; nested exception is
 java.lang.IllegalArgumentException: interface
 org.springframework.aop.framework.Advised is not visible from class
 loader
at
 com.liferay.lock.service.spring.LockServiceUtil.clear(LockServiceUtil.java:48)
 
at
 com.liferay.portal.events.StartupAction.run(StartupAction.java:66)
at
 com.liferay.portal.events.EventsProcessor._process(EventsProcessor.java:144)
 
at
 com.liferay.portal.events.EventsProcessor.process(EventsProcessor.java:73)
at com.liferay.portal.servlet.MainServlet.init(MainServlet.java:135)
at javax.servlet.GenericServlet.init(GenericServlet.java:168)
at
 org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:383)
at
 org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:243)
at
 org.apache.geronimo.jetty.JettyWebAppContext.registerServletHolder(JettyWebAppContext.java:588)
 
at
 org.apache.geronimo.jetty.JettyWebAppContext$$FastClassByCGLIB$$99d6fb54.invoke(generated)
 
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
 org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
 
at
 org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
 
at
 org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
 
at
 org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
 org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
 
at
 org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
 
at
 org.apache.geronimo.management.geronimo.WebModule$$EnhancerByCGLIB$$7577bc9a.registerServletHolder(generated)
 
at
 org.apache.geronimo.jetty.JettyServletHolder.init(JettyServletHolder.java:80)
 
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
 Method)
at

[jira] Assigned: (AMQ-974) .Net client needs centralised trace facility

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

james strachan reassigned AMQ-974:
--

Assignee: james strachan

 .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
 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-695) Dynamic HTTP provider endpoint

2006-10-16 Thread James Lorenzen (JIRA)

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

James Lorenzen updated SM-695:
--

Attachment: ProviderProcessor.java

I incorporated Guillaume's feedback.
Created a method variable that defaults to the endpoint.getLocationURI. This
variable's value is overridden is the property is present.
All the tests for HttpProviderTest passed.

Please let me know what else I need to do.

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: Patched submitted for SM-695. Desire feedback

2006-10-16 Thread jlo_gestalt


I incorporated your feedback Guillaume. Thanks again.
I created a method variable that defaults to the endpoint.getLocationURI().
This variable's value is overridden if the property is present.
All the tests for HttpProviderTest passed.

I attached ProviderProcessor as a patch again with the latest changes.

Please let me know what else I need to do.

-- 
View this message in context: 
http://www.nabble.com/Patched-submitted-for-SM-695.-Desire-feedback-tf2438942.html#a6837904
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.

geronimo on jconsole

2006-10-16 Thread anita kulshreshtha

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.ThanksAnita 
		 All-new Yahoo! Mail - Fire up a more powerful email and get things done faster.

[jira] Commented: (GERONIMO-2495) Build error: server/config/j2ee-corba-* plans refer to corba-tss-config-2.0 instead of corba-tss-config-2.1

2006-10-16 Thread Mark DeLaFranier (JIRA)

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

Mark DeLaFranier commented on GERONIMO-2495:


In order to test your theory, I did the followin:

1. Reverted j2ee-corba-sun/src/plan/plan.xml
2. From within the server/configs/j2ee-corba-sun directory ran the following:

mvn -o clean
mvn -o compile
mvn -o install

This did not reproduce the original error.

3. I then decided to perform a clean and build via (from the server directory)

mvn -o clean
mvn -o install

It seems that after I changed then plan and did a full build, that I can no 
longer reproduce this problem anymore.  :-(

 Build error: server/config/j2ee-corba-* plans refer to corba-tss-config-2.0 
 instead of corba-tss-config-2.1
 ---

 Key: GERONIMO-2495
 URL: http://issues.apache.org/jira/browse/GERONIMO-2495
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: buildsystem
Affects Versions: 1.2
 Environment: windows xp
Reporter: Mark DeLaFranier
 Attachments: corba-plan-patch.txt


 While building the latest codeline, the build failed due to bad references in 
 the xml namespace.  The following plans:
 j2ee-corba-sun/src/plan/plan.xml
 j2ee-corba-yoko/src/plan/plan.xml
 refer to the namespace:
 http://www.openejb.org/xml/ns/corba-tss-config-2.0
 but looking at the openejb2 codeline, I only find:
 http://www.openejb.org/xml/ns/corba-tss-config-2.1
 From:
 openejb/openejb2/modules/openejb-builder/src/main/xsd/corba-tss-config-2.1.xsd

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

[VOTE] Release XBean 2.7

2006-10-16 Thread Guillaume Nodet


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

[jira] Commented: (AMQ-855) Add support for prefetchSize = 0

2006-10-16 Thread Vadim Pesochinskiy (JIRA)

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

Vadim Pesochinskiy commented on AMQ-855:


I think you are right.

 Add support for prefetchSize = 0
 

 Key: AMQ-855
 URL: https://issues.apache.org/activemq/browse/AMQ-855
 Project: ActiveMQ
  Issue Type: New Feature
  Components: Broker
Affects Versions: 4.0.2, 4.0.1, 4.0
 Environment: any
Reporter: Vadim Pesochinskiy
 Assigned To: Hiram Chirino
Priority: Critical
 Fix For: 4.1

 Attachments: ActiveMQMessageConsumer.java.patch3, 
 ActiveMQMessageConsumer.patch, ActiveMQMessageConsumer.patch2, 
 PrefetchSubscription.java.patch2, PrefetchSubscription.java.patch3, 
 PrefetchSubscription.patch, region.QueueSubscription.java.patch, 
 ZeroPrefetchConsumerTest.java.patch, ZeroPrefetchConsumerTest.java.patch3


 This feature would enable to support following test case:
 2 servers are processing 3 submitted jobs with following processing times 10 
 min, 1 min, 1 min. This sequence should finish in 10 minutes as one service 
 will pick up the 10 minutes job, meanwhile the other one should manage the 
 two 1 minute jobs. Since I cannot set prefetchSize=0, one of the 1 minute 
 jobs is sitting in prefetch buffer and the jobs are processed in 11 minutes 
 instead of 10.
 This is simplification of the real scenario where I have about 30 consumers 
 submitting jobs to 20 consumers through AMQ 4.0.1. I have following problems:
  Messages are sitting in prefetch buffer are not available to processors, 
 which results in a lot of idle time.
  Order of processing is random. For some reason Job # 20 is processed after 
 Job # 1500. Since senders are synchronously blocked this can result in 
 time-outs.
  Some requests are real-time, i.e. there is a user waiting, so the system 
 cannot wait, so AMQ-850 does not fix this issue.

-- 
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: DayTrader with an AJAX based Web interface

2006-10-16 Thread Paul McMahan


On 10/16/06, Christopher Blythe [EMAIL PROTECTED] wrote:

Any initial thoughts on how we should start integrating this into the source
tree?

As I mentioned previously, I currently have the dojo interface module and
web services proxy module in individual wars packaged in a separate ear. Do
we want to keep this deployment model?

Or would it make more sense to package the wars directly in the trade ear?

Thoughts or opinions?


I'd recommend keeping the dojo library outside the daytrader ear.
That way you'll keep your options open when migrating daytrader to
Geronimo 1.2 which already has dojo deployed at the context /dojo.

Best wishes,
Paul

Re: [VOTE] Release XBean 2.7


+1

On 10/16/06, Guillaume Nodet [EMAIL PROTECTED] 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




--

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

Re: [VOTE] Release XBean 2.7

2006-10-16 Thread Jason Dillon


+1

--jason


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

[jira] Resolved: (AMQ-974) .Net client needs centralised trace facility

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

james strachan resolved AMQ-974.


Fix Version/s: 4.1
   Resolution: Fixed

Patch applied - many thanks!

 .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

Re: svn commit: r464585 - /geronimo/genesis/trunk/config/project-config/pom.xml

2006-10-16 Thread Jason Dillon


Nope, still problems after this...

--jason


On Oct 16, 2006, at 10:51 AM, [EMAIL PROTECTED] wrote:


Author: jdillon
Date: Mon Oct 16 10:51:39 2006
New Revision: 464585

URL: http://svn.apache.org/viewvc?view=revrev=464585
Log:
Disable the tools profile for now to test crazy mvn snapshot muck

Modified:
geronimo/genesis/trunk/config/project-config/pom.xml

Modified: geronimo/genesis/trunk/config/project-config/pom.xml
URL: http://svn.apache.org/viewvc/geronimo/genesis/trunk/config/ 
project-config/pom.xml?view=diffrev=464585r1=464584r2=464585
== 


--- geronimo/genesis/trunk/config/project-config/pom.xml (original)
+++ geronimo/genesis/trunk/config/project-config/pom.xml Mon Oct 16  
10:51:39 2006

@@ -509,6 +509,10 @@
 /activation
 /profile

+!--
+NOTE: There were some reports of this profile causing  
strange snapshot problems,

+  disabling for now to try and debug.
+
 profile
 idtools/id

@@ -526,6 +530,7 @@
 /plugins
 /build
 /profile
+--
 /profiles

 reporting

[jira] Assigned: (AMQ-973) .Net client sends message acknowledgements as synchronous requests instead of asynchronous oneWay packets

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

james strachan reassigned AMQ-973:
--

Assignee: james strachan  (was: Rob Lugt)

 .Net client sends message acknowledgements as synchronous requests instead of 
 asynchronous oneWay packets
 -

 Key: AMQ-973
 URL: https://issues.apache.org/activemq/browse/AMQ-973
 Project: ActiveMQ
  Issue Type: Bug
  Components: NMS (C# client)
Affects Versions: 4.0.2
 Environment: Windows
Reporter: Rob Lugt
 Assigned To: james strachan
 Attachments: amq973-patch.txt


 The Java client sends message acknowledgements as one-way communications, but 
 the NMS client currently sends these as synchronous requests.  This is 
 impacting performance and is (I believe) unnecessary.

-- 
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: Maven's snapshot mechanism is horked (Re: Build error - Is it from svn commit: r463555 - /geronimo/genesis/trunk/config/project-config/pom.xml?)

2006-10-16 Thread Jason Dillon

I think I have tracked this down... looks like ${pom.version} is  
getting resolved to a timestamp version instead of the value it its  
parents version element.


Is this expected?

If my parent has 1.1-SNAPSHOT, and an intermediate module defines a  
dependency using ${pom.version}, should this resolve to 1.1-SNAPSHOT  
or to 1.1-timestamp-build for the current module?


--jason


On Oct 14, 2006, at 6:58 AM, Kenney Westerhof wrote:

The problem below seems to indicate that the local repository  
contains an old metadata file.


Running mvn with -U -cpu should fix that (or wait 24 hours and try  
again :)).


Another solution is to delete the metadata file from the local  
repository.


Btw, how come the original snapshot versions are removed from the  
remote repository?
The local metadata file probably contains a reference to the old  
snapshot version,

but doesn't seem to have it locally, which needs investigation..

As for the other snapshot errors: Maven 1 legacy repositories don't  
contain metadata files. Updating snapshots from them doesn't seem  
to work. That's another thing that

should be investigated.

I personally never have problems with snapshot versions, so maybe  
the use of maven 1 repositories
and the removal of snapshots from the remote repository isn't  
handled correctly by Maven.


-- Kenney

Jason Dillon wrote:
Folks... maven's handling of *SNAPSHOT artifacts is killing us.   
Any idea what is going on... and how we can fix this.  Its an  
ongoing problem, seems like new timestamp mismatch problems are  
popping up quite often now.  I've already removed our direct use  
of m1 repos to get around some problems resolving artifacts... but  
something is still very broken with maven's SNAPSHOT mechanism.

Any ideas?
--jason
Begin forwarded message:

From: Jason Dillon [EMAIL PROTECTED]
Date: October 13, 2006 2:00:50 PM PDT
To: dev@geronimo.apache.org
Cc: Jason van Zyl [EMAIL PROTECTED]
Subject: Maven's snapshot mechanism is horked (Re: Build error -  
Is it from svn commit: r463555 - /geronimo/genesis/trunk/config/ 
project-config/pom.xml?)


Yes, build genesis locally for now to get around... I'm gonna  
need to get the maven peeps to explain wtf is going on... and  
hopefully fix maven to not freak out like this.


The metadata for plugin-support is correct... showing the latest  
1.1-SNAPSHOT is -23:


metadata
  groupIdorg.apache.geronimo.genesis.plugins/groupId
  artifactIdplugin-support/artifactId
  version1.1-SNAPSHOT/version
  versioning
snapshot
  timestamp20061013.014841/timestamp
  buildNumber23/buildNumber
/snapshot
lastUpdated20061013014947/lastUpdated
  /versioning
/metadata

And -23 is there:

http://people.apache.org/repo/m2-snapshot-repository/org/apache/ 
geronimo/genesis/plugins/plugin-support/1.1-SNAPSHOT/plugin- 
support-1.1-20061013.014841-23.jar
http://people.apache.org/repo/m2-snapshot-repository/org/apache/ 
geronimo/genesis/plugins/plugin-support/1.1-SNAPSHOT/plugin- 
support-1.1-20061013.014841-23.pom


So, Maven *should* be resolving any 1.1-SNAPSHOT of plugin-config  
to these files... but...


--jason


On Oct 13, 2006, at 1:50 PM, Joe Bohn wrote:

Prasad and I hit the same problem earlier today.  There must be  
something strange going on with the version # where 21 is  
being assumed instead of the 23 that is actually in the repo.   
I'm hoping that Jason will know what exactly is going on and how  
to fix it and I suspect it may be related to one of his changes.


To get around the problem for now you can build genesis  
locally.  That worked for me.


Joe


Donald Woods wrote:
Having build problems today and wondering if the below genesis  
change yesterday is causing it?
Started with a new trunk checkout directory on a SLES10 x86  
machine.

Removed the existing .m2 repo.
bootstrap clean ran fine.
bootstrap specs is failing (also tried mvn -U install from  
target/external/specs) because the file  
version=1.1-20061013.014841-21 is not in the snapshot repo, but  
version=1.1-20061013.014841-23 is.
-- 
--

[ERROR] BUILD ERROR
[INFO]  
-- 
--

[INFO] Failed to resolve artifact.
Missing:
--
1) org.apache.geronimo.genesis.plugins:plugin-support:jar:1.1- 
SNAPSHOT

  Try downloading the file manually from the project website.
  Then, install it using the command:
  mvn install:install-file - 
DgroupId=org.apache.geronimo.genesis.plugins - 
DartifactId=plugin-support \
  -Dversion=1.1-20061013.014841-21 -Dpackaging=jar - 
Dfile=/path/to/file

  Path to dependency:
1) org.apache.geronimo.genesis.plugins:tools-maven- 
plugin:maven-plugin:1.1-20061013.014841-21 2)  
org.apache.geronimo.genesis.plugins:plugin-support:jar: 
1.1-20061013.014841-21 --

1 required artifact is missing.
for artifact:
org.apache.geronimo.genesis.plugins:tools-maven-plugin:maven-

Re: [Results] Priorities for 1.2

2006-10-16 Thread Joe Bohn


Dain,

Could you clarify the Full Java 5 support item some more?   I was 
under the impression when I first read this (esp. the statement about 
certification) that this was the work necessary to get to JEE5. 
However, others have indicated that this is really certification (TCK at 
the 1.4 spec level) but now on a 1.5 JVM.


Thanks,
Joe


Dain Sundstrom wrote:

The results are in!  We had a good number of respondents, and the
results are quite clear.  Last night I spent a few hours tallying the
results and analyzing them.   There was a very clean ordering from the
most popular to the least.  Additionally, the features clearly fell
into categories.

Top
---
These features were easily visually separated from the others.  They
tended to have a lot of #1 ranking and almost no low rankings.
Additionally, these are the most clearly defined, have several people
working on them, and are already mostly complete.  This the feature
set that will define the 1.2 release.

Full Java 5 support (really is certification on Java 5) - Dain, Jencks 
and Rick

OpenJPA integration - Blevins and Jencks
Yoko ORB support - Rick and Jencks
Global JNDI - Dain and Jencks

Some support

These features had a few very few 1-2 rankings, but many 3-5 rankings.
Additionally, the also had a a few lower half rankings.
Additionally, Console usability improvements and More server
modularization via plugins are improvements and not features.  I do
not believe that anyone is working in Console extensibility or
OpenEJB 3.0 integration with @Stateless with an eye for inclusion in
1.2 and these features are likely to be quite destabilizing.
Therefor, they will not be included in the 1.2 release.

Console usability improvements
Console extensibility
More server modularization via plugins
OpenEJB 3.0 integration with @Stateless

Little Support
--
These features had a small amount of support noted buy a single vote
for a top 3 ranking, and normally a supporting vote for a top 5
ranking (except CMP which only had a single #2 vote).  Therefor, I
think these features are best demonstrated via a plugin or branch to
gather more support before they are included in any release.

More out of the box samples
Geronimo OSGi bundle
GShell integration
CMP improvements

No Support
--
These features had no rankings in the top half (1-7).

JAF 1.1
Jetspeed integration


-dain.

[jira] Resolved: (AMQ-973) .Net client sends message acknowledgements as synchronous requests instead of asynchronous oneWay packets

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

james strachan resolved AMQ-973.


Fix Version/s: 4.1
   Resolution: Fixed

Patch applied - many thanks!

 .Net client sends message acknowledgements as synchronous requests instead of 
 asynchronous oneWay packets
 -

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

 Attachments: amq973-patch.txt


 The Java client sends message acknowledgements as one-way communications, but 
 the NMS client currently sends these as synchronous requests.  This is 
 impacting performance and is (I believe) unnecessary.

-- 
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: Maven 2 packages for 4.0.1 release?


On 10/13/06, Sakala, Adinarayana [EMAIL PROTECTED] wrote:

Hi,

I am planning to update CXF project to use ActiveMQ 4.0.1 release.
Currently it uses 3.2.

Where can I find the Maven 2 snapshots for 4.0.1 release?


4.0.x uses Maven 1 for its building  distribution. It might be worth
going straight to 4.1.x which uses maven 2. There are snapshots
already in the incuabtor snapshot repo and hopefully we'll have 4.1
released pretty soon...

http://people.apache.org/maven-snapshot-repository/org/apache/activemq/apache-activemq/4.1-incubator-SNAPSHOT/
--

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

Re: DayTrader with an AJAX based Web interface

2006-10-16 Thread J. Stan Cox



I agree and would also suggest keeping the dojo based web app in the 
separate EAR for now. Thus the dojo ear can be updated/developed on a 
base DayTrader version.


Stan.


Paul McMahan wrote:

On 10/16/06, Christopher Blythe [EMAIL PROTECTED] wrote:
Any initial thoughts on how we should start integrating this into the 
source

tree?

As I mentioned previously, I currently have the dojo interface module 
and
web services proxy module in individual wars packaged in a separate 
ear. Do

we want to keep this deployment model?

Or would it make more sense to package the wars directly in the trade 
ear?


Thoughts or opinions?


I'd recommend keeping the dojo library outside the daytrader ear.
That way you'll keep your options open when migrating daytrader to
Geronimo 1.2 which already has dojo deployed at the context /dojo.

Best wishes,
Paul

[jira] Resolved: (AMQ-855) Add support for prefetchSize = 0

2006-10-16 Thread Hiram Chirino (JIRA)

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

Hiram Chirino resolved AMQ-855.
---

Resolution: Fixed

Fix for 'sendPullCommand(0)' issue applied to trunk revision 464643

 Add support for prefetchSize = 0
 

 Key: AMQ-855
 URL: https://issues.apache.org/activemq/browse/AMQ-855
 Project: ActiveMQ
  Issue Type: New Feature
  Components: Broker
Affects Versions: 4.0, 4.0.1, 4.0.2
 Environment: any
Reporter: Vadim Pesochinskiy
 Assigned To: Hiram Chirino
Priority: Critical
 Fix For: 4.1

 Attachments: ActiveMQMessageConsumer.java.patch3, 
 ActiveMQMessageConsumer.patch, ActiveMQMessageConsumer.patch2, 
 PrefetchSubscription.java.patch2, PrefetchSubscription.java.patch3, 
 PrefetchSubscription.patch, region.QueueSubscription.java.patch, 
 ZeroPrefetchConsumerTest.java.patch, ZeroPrefetchConsumerTest.java.patch3


 This feature would enable to support following test case:
 2 servers are processing 3 submitted jobs with following processing times 10 
 min, 1 min, 1 min. This sequence should finish in 10 minutes as one service 
 will pick up the 10 minutes job, meanwhile the other one should manage the 
 two 1 minute jobs. Since I cannot set prefetchSize=0, one of the 1 minute 
 jobs is sitting in prefetch buffer and the jobs are processed in 11 minutes 
 instead of 10.
 This is simplification of the real scenario where I have about 30 consumers 
 submitting jobs to 20 consumers through AMQ 4.0.1. I have following problems:
  Messages are sitting in prefetch buffer are not available to processors, 
 which results in a lot of idle time.
  Order of processing is random. For some reason Job # 20 is processed after 
 Job # 1500. Since senders are synchronously blocked this can result in 
 time-outs.
  Some requests are real-time, i.e. there is a user waiting, so the system 
 cannot wait, so AMQ-850 does not fix this issue.

-- 
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: [Results] Priorities for 1.2

2006-10-16 Thread Dain Sundstrom


On Oct 16, 2006, at 11:28 AM, Joe Bohn wrote:


Dain,

Could you clarify the Full Java 5 support item some more?   I was  
under the impression when I first read this (esp. the statement  
about certification) that this was the work necessary to get to  
JEE5. However, others have indicated that this is really  
certification (TCK at the 1.4 spec level) but now on a 1.5 JVM.


Certification on a Java 5 VM.

-dain

Re: [VOTE] Release XBean 2.7


+1

Jacek

On 10/16/06, Guillaume Nodet [EMAIL PROTECTED] 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




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

Re: [VOTE] Release XBean 2.7

2006-10-16 Thread Dain Sundstrom


+1

-dain

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

[VOTE] Release Servicemix 3.0.1

2006-10-16 Thread Guillaume Nodet


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

Re: [VOTE] Release XBean 2.7

2006-10-16 Thread Alan Cabrera


+1

Regards,
Alan


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

2006-10-16 Thread Ramon Buckland

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

2006-10-16 Thread Grant McDonald

+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 Liferay Plugins

Ok. Made the dir browseable.Will be happy to share the PPTs with you once I finish them.--Brian ChanChief Software ArchitectLiferay, Inc.Enterprise. Open Source. For Life.On 10/16/06 5:10 AM,Jacek Laskowski [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

Re: Geronimo Liferay Plugins



Brian Chan wrote:
 Paul, that stacktrace looks very very similar.
 

I am pretty certain it is the deployer filter...I am willing to bet some
large quantity of beers that if Paul removes the Spring filter from the
jetty deployer plan file, it will work ;-)  I remember that error pretty
well when we worked on the Enterprise Liferay and it took a good day to
figure it out...

Paul needs to remove the Spring and Antlr hidden classes from the jetty
deployer plan.


Jeff


 I believe I actually had to do a fix on the Liferay code itself. Are you
 using Liferay trunk?
 
 --
 Brian Chan
 Chief Software Architect
 Liferay, Inc.
 Enterprise. Open Source. For Life.
 
 On 10/16/06 9:08 AM, Paul McMahan [EMAIL PROTECTED] mailto:
 [EMAIL PROTECTED] wrote:
 
 On 10/16/06, Jeff Genender  wrote:


 Paul McMahan wrote:
  Also, I worked on a Jetty version of the plugin but encountered some
  problems with classloading that I think may be due to the Jetty
  assembly pulling in Spring and/or cglib differently than the Tomcat
  assembly?  I saw a couple of emails go by last week about issues with
  Spring in the Jetty assembly, perhaps that could be related.  I
  haven't drilled down far enough to know the real culprit yet.

 I suspect a hidden-classes declaration in the Liferay environment will
 fix this for you.
 
 I suspected that at first and added this to geronimo-application.xml :
   
 org.springframework
   
 
 But I still get the ST at the bottom of this note, the following
 portion looking especially suspect:
   interface org.springframework.aop.framework.Advised is not visible
 from class loader
 
 I've tried several other different variations of using
 , , and  to work
 around this.   But without a thorough understanding of the underlying
 problem I'm starting to feel like I'm taking shots in the dark.
 Unless there's enough information in the ST below to trigger some
 suggestions I suppose I just need to bite the bullet and crawl through
 startup with a debugger :-)
 
 BTW, the magic ingredient that worked for me in creating the 4.0.0
 Liferay plugin for Geronimo's 1.1 tomcat assembly was:
   
 org.apache.commons.logging
 org.apache.velocity
 org.springframework
 
   
 net.sf.cglib
 
 This forced Geronimo to use Spring from Liferay but cglib from
 Geronimo.  But now the tomcat liferay plugin doesn't need this and the
 same plan doesn't work for Jetty.
 
 com.liferay.portal.SystemException:
 org.springframework.beans.factory.BeanCreationException: Error
 creating bean with name
 'com.liferay.lock.service.spring.LockServiceFactory' defined in class
 path resource [META-INF/lock-spring-enterprise.xml]: Cannot resolve
 reference to bean
 'com.liferay.lock.service.spring.LockService.enterprise' while setting
 bean property 'service'; nested exception is
 org.springframework.beans.factory.BeanCreationException: Error
 creating bean with name
 'com.liferay.lock.service.spring.LockService.enterprise' defined in
 class path resource [META-INF/lock-spring-enterprise.xml]:
 Initialization of bean failed; nested exception is
 java.lang.IllegalArgumentException: interface
 org.springframework.aop.framework.Advised is not visible from class
 loader
 at 
 com.liferay.lock.service.spring.LockServiceUtil.clear(LockServiceUtil.java:48)
 at com.liferay.portal.events.StartupAction.run(StartupAction.java:66)
 at 
 com.liferay.portal.events.EventsProcessor._process(EventsProcessor.java:144)
 at 
 com.liferay.portal.events.EventsProcessor.process(EventsProcessor.java:73)
 at com.liferay.portal.servlet.MainServlet.init(MainServlet.java:135)
 at javax.servlet.GenericServlet.init(GenericServlet.java:168)
 at 
 org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:383)
 at 
 org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:243)
 at 
 org.apache.geronimo.jetty.JettyWebAppContext.registerServletHolder(JettyWebAppContext.java:588)
 at 
 org.apache.geronimo.jetty.JettyWebAppContext$$FastClassByCGLIB$$99d6fb54.invoke()
 at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
 at 
 org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
 at 
 org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
 at 
 org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
 at 
 org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
 at 
 org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
 at 
 org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
 at

Re: Geronimo Liferay Plugins

Paul, that stacktrace looks very very similar.I believe I actually had to do a fix on the Liferay code itself. Are you using Liferay trunk?--Brian ChanChief Software ArchitectLiferay, Inc.Enterprise. Open Source. For Life.On 10/16/06 9:08 AM,Paul McMahan [EMAIL PROTECTED] wrote:On 10/16/06, Jeff Genender  wrote:


 Paul McMahan wrote:
  Also, I worked on a Jetty version of the plugin but encountered some
  problems with classloading that I think may be due to the Jetty
  assembly pulling in Spring and/or cglib differently than the Tomcat
  assembly?  I saw a couple of emails go by last week about issues with
  Spring in the Jetty assembly, perhaps that could be related.  I
  haven't drilled down far enough to know the real culprit yet.

 I suspect a hidden-classes declaration in the Liferay environment will
 fix this for you.

I suspected that at first and added this to geronimo-application.xml :
		
org.springframework
		

But I still get the ST at the bottom of this note, the following
portion looking especially suspect:
  interface org.springframework.aop.framework.Advised is not visible
from class loader

I've tried several other different variations of using
, , and  to work
around this.   But without a thorough understanding of the underlying
problem I'm starting to feel like I'm taking shots in the dark.
Unless there's enough information in the ST below to trigger some
suggestions I suppose I just need to bite the bullet and crawl through
startup with a debugger :-)

BTW, the magic ingredient that worked for me in creating the 4.0.0
Liferay plugin for Geronimo's 1.1 tomcat assembly was:
		
org.apache.commons.logging
org.apache.velocity
org.springframework

		
net.sf.cglib

This forced Geronimo to use Spring from Liferay but cglib from
Geronimo.  But now the tomcat liferay plugin doesn't need this and the
same plan doesn't work for Jetty.

com.liferay.portal.SystemException:
org.springframework.beans.factory.BeanCreationException: Error
creating bean with name
'com.liferay.lock.service.spring.LockServiceFactory' defined in class
path resource [META-INF/lock-spring-enterprise.xml]: Cannot resolve
reference to bean
'com.liferay.lock.service.spring.LockService.enterprise' while setting
bean property 'service'; nested exception is
org.springframework.beans.factory.BeanCreationException: Error
creating bean with name
'com.liferay.lock.service.spring.LockService.enterprise' defined in
class path resource [META-INF/lock-spring-enterprise.xml]:
Initialization of bean failed; nested exception is
java.lang.IllegalArgumentException: interface
org.springframework.aop.framework.Advised is not visible from class
loader
at com.liferay.lock.service.spring.LockServiceUtil.clear(LockServiceUtil.java:48)
at com.liferay.portal.events.StartupAction.run(StartupAction.java:66)
at com.liferay.portal.events.EventsProcessor._process(EventsProcessor.java:144)
at com.liferay.portal.events.EventsProcessor.process(EventsProcessor.java:73)
at com.liferay.portal.servlet.MainServlet.init(MainServlet.java:135)
at javax.servlet.GenericServlet.init(GenericServlet.java:168)
at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:383)
at org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:243)
at org.apache.geronimo.jetty.JettyWebAppContext.registerServletHolder(JettyWebAppContext.java:588)
at org.apache.geronimo.jetty.JettyWebAppContext$$FastClassByCGLIB$$99d6fb54.invoke()
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at org.apache.geronimo.management.geronimo.WebModule$$EnhancerByCGLIB$$7577bc9a.registerServletHolder()
at org.apache.geronimo.jetty.JettyServletHolder.(JettyServletHolder.java:80)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:933)
at

Re: Geronimo Liferay Plugins

Sure thing Paul. Just let me know what to do for the Jetty and 1.2.x plugin.--Brian ChanChief Software ArchitectLiferay, Inc.Enterprise. Open Source. For Life.On 10/16/06 8:08 AM,Paul McMahan [EMAIL PROTECTED] wrote:On 10/16/06, Aaron Mulder  wrote:
 On 10/14/06, Brian Chan  wrote:
  The latest Liferay portal plugins are now available on.
 
  http://geronimo.liferay.com/plugins

 Nice!

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

 We can actually add it for 1.1.1 if you like -- according to the
 plugin metadata, this same plugin works in both 1.1.1 and
 1.2-SNAPSHOT.  Is that right; has it been tested in both?

The plugins work fine for me in Geronimo 1.1.1.  I agree it would be a
great idea to add this repo to the default repository list for 1.1.1.
However, in Geronimo 1.2 our group id changed from geronimo to
org.apache.geronimo so we'll need new versions of the plugins that
reference the Geronimo prerequisites correctly for that release.  I
can offer my assistance to Liferay on creating them.  IIUC the
tentative plan is to release Geronimo 1.2 towards the end of this
year, so we should coordinate things around that timeframe.

Also, I worked on a Jetty version of the plugin but encountered some
problems with classloading that I think may be due to the Jetty
assembly pulling in Spring and/or cglib differently than the Tomcat
assembly?  I saw a couple of emails go by last week about issues with
Spring in the Jetty assembly, perhaps that could be related.  I
haven't drilled down far enough to know the real culprit yet.

Best wishes,
Paul

Re: Geronimo Liferay Plugins