date:20080627


[ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608110#action_12608110
 ] 

mcconne edited comment on GERONIMODEVTOOLS-290 at 6/27/08 6:42 PM:
-

(/) 
http://geronimo.apache.org/developing-the-geronimo-eclipse-plugin-in-eclipse.html

  was (Author: mcconne):
(x) 
http://geronimo.apache.org/developing-the-geronimo-eclipse-plugin-in-eclipse.html
  
> Documentation updates
> -
>
> Key: GERONIMODEVTOOLS-290
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-290
> Project: Geronimo-Devtools
>  Issue Type: Sub-task
>Reporter: Tim McConnell
>Assignee: Tim McConnell
> Fix For: 2.1.1
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GERONIMODEVTOOLS-290) Documentation updates


 [ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tim McConnell closed GERONIMODEVTOOLS-290.
--

Resolution: Fixed

> Documentation updates
> -
>
> Key: GERONIMODEVTOOLS-290
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-290
> Project: Geronimo-Devtools
>  Issue Type: Sub-task
>Reporter: Tim McConnell
>Assignee: Tim McConnell
> Fix For: 2.1.1
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (GERONIMODEVTOOLS-290) Documentation updates


[ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608080#action_12608080
 ] 

mcconne edited comment on GERONIMODEVTOOLS-290 at 6/27/08 6:41 PM:
-

(/) 
http://cwiki.apache.org/GMOxDOC21/development-environment.html#Developmentenvironment-InstallingEclipse

  was (Author: mcconne):
(x) 
http://cwiki.apache.org/GMOxDOC21/development-environment.html#Developmentenvironment-InstallingEclipse
  
> Documentation updates
> -
>
> Key: GERONIMODEVTOOLS-290
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-290
> Project: Geronimo-Devtools
>  Issue Type: Sub-task
>Reporter: Tim McConnell
>Assignee: Tim McConnell
> Fix For: 2.1.1
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[BUILD] trunk: Failed for Revision: 672448

2008-06-27 Thread gawor

Geronimo Revision: 672448 built with tests included
 
See the full build-2100.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080627/build-2100.log
 
 
See the unit test reports at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080627/unit-test-reports
 

  Then, install it using the command: 
  mvn install:install-file -DgroupId=org.apache.openejb 
-DartifactId=xbean-finder -Dversion=3.4-r636443-SNAPSHOT -Dpackaging=jar 
-Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there: 
  mvn deploy:deploy-file -DgroupId=org.apache.openejb 
-DartifactId=xbean-finder -Dversion=3.4-r636443-SNAPSHOT -Dpackaging=jar 
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
1) org.apache.geronimo.modules:geronimo-openejb:jar:2.2-SNAPSHOT
2) org.apache.openejb:openejb-core:jar:3.1-SNAPSHOT
3) org.apache.openejb:xbean-finder:jar:3.4-r636443-SNAPSHOT

--
2 required artifacts are missing.

for artifact: 
  org.apache.geronimo.modules:geronimo-openejb:jar:2.2-SNAPSHOT

from the specified remote repositories:
  ibiblio.org (http://repo1.maven.org/maven2),
  java.net (http://download.java.net/maven/1/),
  apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository),
  apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository),
  codehaus-snapshots (http://snapshots.repository.codehaus.org),
  apache-incubator (http://people.apache.org/repo/m2-incubating-repository/)

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:575)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: 
org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: Missing:
--
1) org.apache.openejb:xbean-reflect:jar:3.4-r636443-SNAPSHOT

  Try downloading the file manually from the project website.

  Then, install it using the command: 
  mvn install:install-file -DgroupId=org.apache.openejb 
-DartifactId=xbean-reflect -Dversion=3.4-r636443-SNAPSHOT -Dpackaging=jar 
-Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there: 
  mvn deploy:deploy-file -DgroupId=org.apache.openejb 
-DartifactId=xbean-reflect -Dversion=3.4-r636443-SNAPSHOT -Dpackaging=jar 
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
1) org.apache.geronimo.modules:geronimo-openejb:jar:2.2-SNAPSHOT
2) org.apache.openejb:openejb-core:jar:3.1-SNAPSHOT
3) org.apache.openejb:xbean-reflect:jar:3.4-r636443-SNAPSHOT

2) org.apache.openejb:xbean-finder:jar:3.4-r636443-SNAPSHOT

  Try downloading the file manually from the project website.

  Then, install it using the command: 
  mvn install:install-file -DgroupId=org.apache.openejb 
-DartifactId=xbean-finder -Dversion=3.4-r636443-SNAPSHOT -Dpackaging=jar 
-Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there: 
  mvn deploy:deploy-file -DgroupId=org.apache.openejb 
-DartifactId=xbean-finder -Dversion=3.4-r636443-SNAPSHOT -Dpackaging=jar 
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
1) org.apache.geronimo.modules:geronimo-openejb:jar:2.2-SNAPSHOT
2) org.apache.openejb:openejb-core:jar:3.1-SNAPSHOT
3) org.apache.openejb:xbean-finder:jar:3.4-r636443-SNAPSHOT

--
2 required artifacts are missing.

for artifact: 
  org.apache.geronimo.modules:geronimo-openejb:jar:2.2-SNAPSHOT

from the specified remote repositories:
  ibiblio.org (http

[jira] Issue Comment Edited: (GERONIMODEVTOOLS-290) Documentation updates


[ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607803#action_12607803
 ] 

mcconne edited comment on GERONIMODEVTOOLS-290 at 6/27/08 6:32 PM:
-

These tutorials below need to be updated once GEP 2.1.1 is released:

(/) http://cwiki.apache.org/GMOxDOC21/web-application-for-ejb-access.html
(/) 
http://cwiki.apache.org/GMOxDOC21/quick-start-fast-and-easy-development.html

  was (Author: mcconne):
These tutorials below need to be updated once GEP 2.1.1 is released:

(/) http://cwiki.apache.org/GMOxDOC21/web-application-for-ejb-access.html
(x) 
http://cwiki.apache.org/GMOxDOC21/quick-start-fast-and-easy-development.html
  
> Documentation updates
> -
>
> Key: GERONIMODEVTOOLS-290
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-290
> Project: Geronimo-Devtools
>  Issue Type: Sub-task
>Reporter: Tim McConnell
>Assignee: Tim McConnell
> Fix For: 2.1.1
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (GERONIMODEVTOOLS-367) unable to include modules and ext-modules


 [ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tim McConnell resolved GERONIMODEVTOOLS-367.


Resolution: Fixed

Patch works good and applied at revision 6725450. We need to be a bit more 
careful about adding new files without the "@version $Rev$ $Date$". Since new 
classes were getting adding via this patch I've corrected those java and xml 
files missing it. 

> unable to include modules and ext-modules
> -
>
> Key: GERONIMODEVTOOLS-367
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-367
> Project: Geronimo-Devtools
>  Issue Type: Sub-task
>  Components: eclipse-plugin
>Affects Versions: 2.1.x
>Reporter: B.J. Reed
>Assignee: B.J. Reed
>Priority: Minor
> Fix For: 2.1.2
>
> Attachments: GERONIMODEVTOOLS-367.patch
>
>
> The application deployment plan editor does not have a way to maintain the 
> module and ext-module lists.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: svn commit: r672379 - in /geronimo/devtools/eclipse-plugin/trunk: features/org.apache.geronimo.v21.feature/ plugins/org.apache.geronimo.runtime.v21/ plugins/org.apache.geronimo.runtime.v21/META-IN

2008-06-27 Thread Tim McConnell

Could be -- I just copied the "2.2-SNAPSHOT" from the server trunk pom.xml since 
we need the GEP trunk to work with those artifacts.


Donald Woods wrote:
Isn't this move to use 2.2-SNAPSHOT jumping the gun a little?  Kevan and 
Joe have discussed a 2.1.2 release in the next 4 to 6 weeks, but I 
haven't seen discussions on a 2.2 target yet



-Donald


[EMAIL PROTECTED] wrote:

Author: mcconne
Date: Fri Jun 27 13:38:20 2008
New Revision: 672379

URL: http://svn.apache.org/viewvc?rev=672379&view=rev
Log:
Update GEP Geronimo version to 2.2-SNAPSHOT

Modified:

geronimo/devtools/eclipse-plugin/trunk/features/org.apache.geronimo.v21.feature/feature.properties 


geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.runtime.v21/LICENSE.txt 


geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.runtime.v21/META-INF/MANIFEST.MF 


geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.runtime.v21/NOTICE.txt 


geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.runtime.v21/pom.xml 



Modified: 
geronimo/devtools/eclipse-plugin/trunk/features/org.apache.geronimo.v21.feature/feature.properties 

URL: 
http://svn.apache.org/viewvc/geronimo/devtools/eclipse-plugin/trunk/features/org.apache.geronimo.v21.feature/feature.properties?rev=672379&r1=672378&r2=672379&view=diff 

== 

--- 
geronimo/devtools/eclipse-plugin/trunk/features/org.apache.geronimo.v21.feature/feature.properties 
(original)
+++ 
geronimo/devtools/eclipse-plugin/trunk/features/org.apache.geronimo.v21.feature/feature.properties 
Fri Jun 27 13:38:20 2008

@@ -201,7 +201,7 @@
 ## ADDITIONAL SOURCE 
LICENSES  ##\n\
 #\n\ 


 \n\
-For geronimo-crypto-2.1.1.jar:\n\
+For geronimo-crypto-2.1.2.jar:\n\
 \n\
 The ASN1 codec implementation in the geronimo-crypto module was\n\
 developed by the Bouncy Castle project. 
(http://www.bouncycastle.org/).\n\


Modified: 
geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.runtime.v21/LICENSE.txt 

URL: 
http://svn.apache.org/viewvc/geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.runtime.v21/LICENSE.txt?rev=672379&r1=672378&r2=672379&view=diff 

== 

--- 
geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.runtime.v21/LICENSE.txt 
(original)
+++ 
geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.runtime.v21/LICENSE.txt 
Fri Jun 27 13:38:20 2008

@@ -205,7 +205,7 @@
 ## ADDITIONAL SOURCE 
LICENSES  ##
 # 

 
-For geronimo-crypto-2.1.1.jar:

+For geronimo-crypto-2.1.2.jar:
 
 The ASN1 codec implementation in the geronimo-crypto module was

 developed by the Bouncy Castle project. (http://www.bouncycastle.org/).

Modified: 
geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.runtime.v21/META-INF/MANIFEST.MF 

URL: 
http://svn.apache.org/viewvc/geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.runtime.v21/META-INF/MANIFEST.MF?rev=672379&r1=672378&r2=672379&view=diff 

== 

--- 
geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.runtime.v21/META-INF/MANIFEST.MF 
(original)
+++ 
geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.runtime.v21/META-INF/MANIFEST.MF 
Fri Jun 27 13:38:20 2008

@@ -4,18 +4,18 @@
 Bundle-SymbolicName: org.apache.geronimo.runtime.v21;singleton:=true
 Bundle-Version: 2.1.2
 Require-Bundle: org.apache.geronimo.runtime.common;visibility:=reexport
-Bundle-ClassPath: lib/geronimo-common-2.1.1.jar,
- lib/geronimo-deploy-jsr88-2.1.1.jar,
- lib/geronimo-deployment-2.1.1.jar,
- lib/geronimo-j2ee-schema-2.1.1.jar,
- lib/geronimo-kernel-2.1.1.jar,
- lib/geronimo-plugin-2.1.1.jar,
- lib/geronimo-system-2.1.1.jar,
- lib/geronimo-util-2.1.1.jar,
- lib/geronimo-deploy-config-2.1.1.jar,
+Bundle-ClassPath: lib/geronimo-common-2.2-SNAPSHOT.jar,
+ lib/geronimo-deploy-jsr88-2.2-SNAPSHOT.jar,
+ lib/geronimo-deployment-2.2-SNAPSHOT.jar,
+ lib/geronimo-j2ee-schema-2.2-SNAPSHOT.jar,
+ lib/geronimo-kernel-2.2-SNAPSHOT.jar,
+ lib/geronimo-plugin-2.2-SNAPSHOT.jar,
+ lib/geronimo-system-2.2-SNAPSHOT.jar,
+ lib/geronimo-util-2.2-SNAPSHOT.jar,
+ lib/geronimo-deploy-config-2.2-SNAPSHOT.jar,
  lib/geronimo-javaee-deployment_1.1MR3_spec-1.0.jar,
  lib/plexus-archiver-1.0-alpha-7.jar,
- lib/geronimo-crypto-2.1.1.jar
+ lib/geronimo-crypto-2.2-SNAPSHOT.jar
 Export-Package:   javax.enterprise.deploy.model,
  javax.enterprise.deploy.model.exceptions,

Modified: 
geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.runtime.v21/NOTICE.txt 

URL: 
http://svn.apache.org/viewv

[jira] Created: (GERONIMO-4170) Upgrade Selenium version for Firefox 3

Upgrade Selenium version for Firefox 3
--

 Key: GERONIMO-4170
 URL: https://issues.apache.org/jira/browse/GERONIMO-4170
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: testsuite
Affects Versions: 2.1.2, 2.2
Reporter: Donald Woods
Priority: Minor


The current Selenium 1.0-beta-1 artifacts do not support using Firefox3 (on 
Linux or MacOSX.)
When a snapshot or next beta does support FF3, then we should upgrade.
The current 1.0-SNAPSHOT artifacts as of the 20080627 version still does not 
work with FF3 on Linux.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (GERONIMODEVTOOLS-392) unable to set hidden-classes and non-overridable-classes for environment


 [ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tim McConnell resolved GERONIMODEVTOOLS-392.


Resolution: Fixed

Works great -- nice work BJ. Applied at revision 672424.

> unable to set hidden-classes and non-overridable-classes for environment
> 
>
> Key: GERONIMODEVTOOLS-392
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-392
> Project: Geronimo-Devtools
>  Issue Type: Sub-task
>  Components: eclipse-plugin
>Affects Versions: 2.1.x
>Reporter: B.J. Reed
>Assignee: B.J. Reed
>Priority: Minor
> Fix For: 2.1.2
>
> Attachments: GERONIMODEVTOOLS-392.patch
>
>
> all deployment plan editors.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMODEVTOOLS-395) should remove tags from source files that have no data


[ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608934#action_12608934
 ] 

Tim McConnell commented on GERONIMODEVTOOLS-395:


Patch 395a works as specified and applied at revision 672410. Thanks BJ for the 
patch !!

> should remove tags from source files that have no data
> --
>
> Key: GERONIMODEVTOOLS-395
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-395
> Project: Geronimo-Devtools
>  Issue Type: Sub-task
>  Components: eclipse-plugin
>Affects Versions: 2.1.x
>Reporter: B.J. Reed
>Assignee: B.J. Reed
>Priority: Minor
> Fix For: 2.1.2
>
> Attachments: GERONIMODEVTOOLS-395a.patch
>
>
> When using any of the deployment plan editors, setting a field to have 
> nothing in it gives an XML tag with nothing in it. Before editing a plan, 
> unnecessary tags are not shown in the deployment plan,  this is the state the 
> plan should revert to.  For example:
> If I use the editor to specify an application client call back handler, I 
> will get a tag like this (which is good)
> aHandler
> Going back into the editor and removing that, I get 
> 
> I was expecting the whole line to just be deleted.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: svn commit: r672379 - in /geronimo/devtools/eclipse-plugin/trunk: features/org.apache.geronimo.v21.feature/ plugins/org.apache.geronimo.runtime.v21/ plugins/org.apache.geronimo.runtime.v21/META-IN

Isn't this move to use 2.2-SNAPSHOT jumping the gun a little?  Kevan and 
Joe have discussed a 2.1.2 release in the next 4 to 6 weeks, but I 
haven't seen discussions on a 2.2 target yet



-Donald


[EMAIL PROTECTED] wrote:

Author: mcconne
Date: Fri Jun 27 13:38:20 2008
New Revision: 672379

URL: http://svn.apache.org/viewvc?rev=672379&view=rev
Log:
Update GEP Geronimo version to 2.2-SNAPSHOT

Modified:

geronimo/devtools/eclipse-plugin/trunk/features/org.apache.geronimo.v21.feature/feature.properties

geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.runtime.v21/LICENSE.txt

geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.runtime.v21/META-INF/MANIFEST.MF

geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.runtime.v21/NOTICE.txt

geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.runtime.v21/pom.xml

Modified: 
geronimo/devtools/eclipse-plugin/trunk/features/org.apache.geronimo.v21.feature/feature.properties
URL: 
http://svn.apache.org/viewvc/geronimo/devtools/eclipse-plugin/trunk/features/org.apache.geronimo.v21.feature/feature.properties?rev=672379&r1=672378&r2=672379&view=diff
==
--- 
geronimo/devtools/eclipse-plugin/trunk/features/org.apache.geronimo.v21.feature/feature.properties
 (original)
+++ 
geronimo/devtools/eclipse-plugin/trunk/features/org.apache.geronimo.v21.feature/feature.properties
 Fri Jun 27 13:38:20 2008
@@ -201,7 +201,7 @@
 ## ADDITIONAL SOURCE LICENSES  ##\n\
 #\n\
 \n\
-For geronimo-crypto-2.1.1.jar:\n\
+For geronimo-crypto-2.1.2.jar:\n\
 \n\
 The ASN1 codec implementation in the geronimo-crypto module was\n\
 developed by the Bouncy Castle project. (http://www.bouncycastle.org/).\n\

Modified: 
geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.runtime.v21/LICENSE.txt
URL: 
http://svn.apache.org/viewvc/geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.runtime.v21/LICENSE.txt?rev=672379&r1=672378&r2=672379&view=diff
==
--- 
geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.runtime.v21/LICENSE.txt
 (original)
+++ 
geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.runtime.v21/LICENSE.txt
 Fri Jun 27 13:38:20 2008
@@ -205,7 +205,7 @@
 ## ADDITIONAL SOURCE LICENSES  ##
 #
 
-For geronimo-crypto-2.1.1.jar:

+For geronimo-crypto-2.1.2.jar:
 
 The ASN1 codec implementation in the geronimo-crypto module was

 developed by the Bouncy Castle project. (http://www.bouncycastle.org/).

Modified: 
geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.runtime.v21/META-INF/MANIFEST.MF
URL: 
http://svn.apache.org/viewvc/geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.runtime.v21/META-INF/MANIFEST.MF?rev=672379&r1=672378&r2=672379&view=diff
==
--- 
geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.runtime.v21/META-INF/MANIFEST.MF
 (original)
+++ 
geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.runtime.v21/META-INF/MANIFEST.MF
 Fri Jun 27 13:38:20 2008
@@ -4,18 +4,18 @@
 Bundle-SymbolicName: org.apache.geronimo.runtime.v21;singleton:=true
 Bundle-Version: 2.1.2
 Require-Bundle: org.apache.geronimo.runtime.common;visibility:=reexport
-Bundle-ClassPath: lib/geronimo-common-2.1.1.jar,
- lib/geronimo-deploy-jsr88-2.1.1.jar,
- lib/geronimo-deployment-2.1.1.jar,
- lib/geronimo-j2ee-schema-2.1.1.jar,
- lib/geronimo-kernel-2.1.1.jar,
- lib/geronimo-plugin-2.1.1.jar,
- lib/geronimo-system-2.1.1.jar,
- lib/geronimo-util-2.1.1.jar,
- lib/geronimo-deploy-config-2.1.1.jar,
+Bundle-ClassPath: lib/geronimo-common-2.2-SNAPSHOT.jar,
+ lib/geronimo-deploy-jsr88-2.2-SNAPSHOT.jar,
+ lib/geronimo-deployment-2.2-SNAPSHOT.jar,
+ lib/geronimo-j2ee-schema-2.2-SNAPSHOT.jar,
+ lib/geronimo-kernel-2.2-SNAPSHOT.jar,
+ lib/geronimo-plugin-2.2-SNAPSHOT.jar,
+ lib/geronimo-system-2.2-SNAPSHOT.jar,
+ lib/geronimo-util-2.2-SNAPSHOT.jar,
+ lib/geronimo-deploy-config-2.2-SNAPSHOT.jar,
  lib/geronimo-javaee-deployment_1.1MR3_spec-1.0.jar,
  lib/plexus-archiver-1.0-alpha-7.jar,
- lib/geronimo-crypto-2.1.1.jar
+ lib/geronimo-crypto-2.2-SNAPSHOT.jar
 Export-Package: 
  javax.enterprise.deploy.model,

  javax.enterprise.deploy.model.exceptions,

Modified: 
geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.runtime.v21/NOTICE.txt
URL: 
http://svn.apache.org/viewvc/geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.runtime.v21/NOTICE.txt?rev=672379&r1=672378&r2=672379&view=diff

[RESULTS] [VOTE] Server Repository plugin for Geronimo 2.1+ (rc3)



Thank you all for reviewing and voting.

The vote passes with 10 +1 and no other votes.

Joe

Joe Bohn wrote:
I've prepared a third release candidate for the Server Repository 
plugin.  This candidate corrects the geronimo-plugin.xml and 
geronimo-plugins.xml issue regarding the open source license.


The rationale for the plugin remains the same:
As a result of some discussion on GERONIMO-2814 
[https://issues.apache.org/jira/browse/GERONIMO-2814] it was suggested 
that we create a plugin to facilitate adding a second repository to 
Geronimo.  This is of particular value when running multiple Geronimo 
server instances from a single Geronimo installation.


I have created a very simple plugin for this purpose.  For more 
information on how this might be leveraged reference 
http://cwiki.apache.org/GMOxDOC21/multiple-repositories.html



Staging repo:
http://people.apache.org/~jbohn/staging-repo/plugins/server-repo/

Staging site:
http://people.apache.org/~jbohn/staging-site/plugins/server-repo/1.0/index.html 



The svn location is here:
https://svn.apache.org/repos/asf/geronimo/plugins/server-repo/tags/server-repo-1.0 



Repository for plugin install (same as staging repo):
http://people.apache.org/~jbohn/staging-repo/plugins/server-repo/
   - From the console navigation to Plugins
   - select Add Repository
   - paste in my staging repo listed above:
   - click Add
   - Select the newly added repository from the drop down list
   - click "Show Plugins in selected repository"
   - You should see just this plugin in the list and you can install it 
from there.



The vote is open for 72 hours and will conclude on Friday (6/27) at 
6:00PM ET.


[ ] +1  Release the server-repo plugin
[ ] +0  No opinion
[ ] -1  Don't release the server-repo plugin


Joe

[jira] Resolved: (GERONIMODEVTOOLS-404) simplify the Dependency GUI code


 [ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tim McConnell resolved GERONIMODEVTOOLS-404.


Resolution: Fixed

Patch applied at revision 672394. Thanks for the patch BJ !!

> simplify the Dependency GUI code
> 
>
> Key: GERONIMODEVTOOLS-404
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-404
> Project: Geronimo-Devtools
>  Issue Type: Sub-task
>  Components: eclipse-plugin
>Affects Versions: 2.1.2
>Reporter: B.J. Reed
>Assignee: B.J. Reed
>Priority: Minor
> Fix For: 2.1.2
>
> Attachments: GERONIMODEVTOOLS-404.patch
>
>
> App Client makes different calls to get and set its environments than the 
> other deployment plan editors.  Should be able to make the DependencyWizard 
> and DependencySection smart enough to handle this rather than making new 
> classes and having specialized code.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [BUILD] trunk: Failed for Revision: 672358


Build failure fixed by r672364.
Still looking into the console testsuite failures...


-Donald


[EMAIL PROTECTED] wrote:

Geronimo Revision: 672358 built with tests included
 
See the full build-1500.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20080627/build-1500.log
 
 
See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/trunk/20080627/unit-test-reports
 
[INFO] Using default encoding to copy filtered resources.

[INFO] [compiler:compile]
[INFO] Compiling 26 source files to 
/home/geronimo/geronimo/trunk/plugins/console/console-core/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] Surefire report directory: 
/home/geronimo/geronimo/trunk/plugins/console/console-core/target/surefire-reports

---
 T E S T S
---
There are no tests to run.

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

[INFO] [jar:jar]
[INFO] Building jar: 
/home/geronimo/geronimo/trunk/plugins/console/console-core/target/console-core-2.2-SNAPSHOT.jar
[INFO] [ianal:verify-legal-files {execution: default}]
[INFO] Checking legal files in: console-core-2.2-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing 
/home/geronimo/geronimo/trunk/plugins/console/console-core/target/console-core-2.2-SNAPSHOT.jar
 to 
/home/geronimo/.m2/repository/org/apache/geronimo/plugins/console-core/2.2-SNAPSHOT/console-core-2.2-SNAPSHOT.jar
[INFO] 
[INFO] Building Geronimo Plugins, ActiveMQ :: Portlets
[INFO]task-segment: [install]
[INFO] 
[INFO] snapshot org.codehaus.mojo.jspc:jspc-maven-plugin:2.0-alpha-2-SNAPSHOT: 
checking for updates from apache-snapshots
[INFO] snapshot org.codehaus.mojo.jspc:jspc-maven-plugin:2.0-alpha-2-SNAPSHOT: 
checking for updates from codehaus-snapshots
[INFO] snapshot org.codehaus.mojo.jspc:jspc-maven-plugin:2.0-alpha-2-SNAPSHOT: 
checking for updates from apache.snapshots
Downloading: 
http://snapshots.repository.codehaus.org/org/codehaus/mojo/jspc/jspc-maven-plugin/2.0-alpha-2-SNAPSHOT/jspc-maven-plugin-2.0-alpha-2-20080504.150315-3.pom
3K downloaded
[INFO] snapshot org.codehaus.mojo.jspc:jspc:2.0-alpha-2-SNAPSHOT: checking for 
updates from apache-snapshots
[INFO] snapshot org.codehaus.mojo.jspc:jspc:2.0-alpha-2-SNAPSHOT: checking for 
updates from codehaus-snapshots
[INFO] snapshot org.codehaus.mojo.jspc:jspc:2.0-alpha-2-SNAPSHOT: checking for 
updates from apache.snapshots
Downloading: 
http://snapshots.repository.codehaus.org/org/codehaus/mojo/jspc/jspc/2.0-alpha-2-SNAPSHOT/jspc-2.0-alpha-2-20080504.150315-4.pom
17K downloaded
Downloading: 
http://snapshots.repository.codehaus.org/org/codehaus/mojo/jspc/jspc-maven-plugin/2.0-alpha-2-SNAPSHOT/jspc-maven-plugin-2.0-alpha-2-20080504.150315-3.jar
32K downloaded
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 41 source files to 
/home/geronimo/geronimo/trunk/plugins/activemq/activemq-portlets/target/classes
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure

/home/geronimo/geronimo/trunk/plugins/activemq/activemq-portlets/src/main/java/org/apache/geronimo/console/jmsmanager/helper/JMSMessageHelperFactory.java:[59,19]
 cannot find symbol
symbol  : method error(java.lang.IllegalAccessException)
location: interface org.slf4j.Logger

/home/geronimo/geronimo/trunk/plugins/activemq/activemq-portlets/src/main/java/org/apache/geronimo/console/jmsmanager/helper/JMSMessageHelperFactory.java:[61,19]
 cannot find symbol
symbol  : method error(java.lang.InstantiationException)
location: interface org.slf4j.Logger

/home/geronimo/geronimo/trunk/plugins/activemq/activemq-portlets/src/main/java/org/apache/geronimo/console/jmsmanager/helper/JMSMessageHelperFactory.java:[63,19]
 cannot find symbol
symbol  : method error(java.lang.ClassNotFoundException)
location: interface org.slf4j.Logger

/home/geronimo/geronimo/trunk/plugins/activemq/activemq-portlets/src/main/java/org/apache/geronimo/console/jmsmanager/helper/AmqJMSMessageHelper.java:[130,15]
 cannot find symbol
symbol  : method error(java.lang.Exception)
location: interface org.slf4j.Logger


[INFO] 
[INFO] Trace
org.apache.maven.BuildFailureException: Compilation failure
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals

Re: making plugins (plugins portlet) more visible in the console

2008-06-27 Thread David Jencks

On Jun 27, 2008, at 12:32 PM, Joe Bohn wrote:

Donald Woods wrote:
Yep, maybe we need to move the samples back into the server tree
(but under their own /samples subdir) for 2.2. That would also
allow us to create a samples-testsuite to verify they work... :-)

There's nothing stopping you from enhancing the smoke tests in trunk,
which verify that the plugins install and start, to actually seeing if
they have the desired functionality. I don't see how moving the
samples elsewhere would make this easier or harder. They can't really
go in testsuite because they are not designed to run in a full server,
they pull in jetty or tomcat.

I removed the 3 remaining samples from the 2.1.1 catalog.

I'm still dead set against merging samples into trunk. I'd be happy
if anyone wanted to move _any_ of the plugins from server/trunk/
plugins to plugins: IMO this is more appropriate direction to move in,
and I thought there was general agreement on this.

I'd expect you'd need the 2.1 to 2.1.1 compatibility plugin installed
for 2.1 samples to work on 2.1.1. Do you guys have that installed?

thanks
david jencks

Joe

Joe Bohn wrote:

Donald Woods wrote:
OK, guess I selected a bad plugin to install from the list and
assumed that they were all bad

I downloaded and installed a clean geronimo-tomcat6-javaee5-2.1.1-
bin.tar.gz

Manually added the 2.1.1 plugin repo -
http://geronimo.apache.org/plugins/geronimo-2.1.1/

Selected the "Geronimo Plugins :: Monitoring Agent (JMX)" and it
installed fine.

If you select the "Geronimo Configs :: Servlet Examples for
Tomcat 2.1-SNAPSHOT - Example" which shows up in the list, it
will FAIL with - "A problem has occured:
org.apache.geronimo.kernel.repository.MissingDependencyException:
Plugin is not installable on Geronimo 2.1.1 Missing dependency:
org.apache.geronimo.samples/servlet-examples-tomcat/2.1-SNAPSHOT/
car"

Guess we need to remove that plugin once we have the Samples
updated and released for 2.1.

Ahh ... I think that when I was updating the catalog for 2.1.1 I
left the LDAP Sample Realm, LDAP Sample, JSP Example, and Servlet
Example in there because of the references from the welcome page.
Since they can not be installed even with the entries I think we
should just go ahead and remove them completely from the 2.1.1
catalog. This won't prevent people from trying via the welcome
page but it will prevent any attempts from the catalog (if they
take the time to switch to the 2.1.1 catalog that is). Is there
any reason to keep these samples in the 2.1.1 catalog for now that
I'm missing? When/if we get samples deployed that can be
installed on 2.1.1 we can add the updated samples back into the
catalog.

This would really be a whole lot more manageable (and correct) if
we were to merge the samples back into the server and release them
concurrently. I know several folks disagree but the current
separation has not yet been successful.

Joe

-Donald

Joe Bohn wrote:

Lin Sun wrote:
Joe, I ran some test against the 2.1.1 plugin repo 2 weeks ago
and I
could not install the sample plugins I tried - forgot the error/
prob

(think I tried the servlet and jsp samples).

Lin

There is 1 problem here and a few misunderstandings based upon
that problem:

Problem:
- The default for the plugin repo for Geronimo 2.1.1 is actually
the plugin repo for 2.1. In order to see the Geronimo 2.1.1
plugin repo you must manually add the repository. See this
thread for a discussion of this issue: http://www.nabble.com/plugin-repository-for-2.1.1-td16990905s134.html

The not yet released samples (2.1-SNAPSHOT) are tied to Geronimo
2.1 and not Geronimo 2.1.1. This is why I have been interested
in getting samples released for 2.1 and 2.1.1. The 2.1-SNAPSHOT
samples appear in the 2.1 repository but not the 2.1.1
repository. So, if you reference the 2.1.1 repository you will
not see the samples listed at all and not encounter a problem on
the install. Of course, that is tricky to do since we show you
the wrong repository by default in 2.1.1.

So, I think what happened was that you accessed the 2.1
repository from a 2.1.1 server and attempted to install one of
the sample plugins from there.

There is one more problem that you or others may hit regarding
attempts to install samples in 2.1.1 at this time. The servlet,
jsp, and ldap samples are referenced directly from default/
welcome servlet (/) and can optionally be installed from there.
An attempt to install them from this location will also fail
given that it is referencing the same incorrect, default plugin
repo for 2.1.

To summarize ... the 2.1.1 repo is not broken AFAIK (if it is
broken then we can easily fix it). What is broken is that 2.1.1
references the wrong plugin repo by default. That problem will
be fixed when we release 2.1.2.

Joe

On Fri, Jun 27, 2008 at 9:09 AM, Joe Bohn
<[EMAI

Re: [ANNOUNCE] Lin Sun is the newest member of the Geronimo PMC

2008-06-27 Thread Jacek Laskowski

On Thu, Jun 26, 2008 at 7:34 PM, Jarek Gawor <[EMAIL PROTECTED]> wrote:

> Congratulations Lin!

Congrats Lin!

Jacek

-- 
Jacek Laskowski
Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl

Re: svn commit: r672364 - /geronimo/site/trunk/docs/plugins/geronimo-2.1.1/geronimo-plugins.xml

2008-06-27 Thread Lin Sun

Joe, thanks for removing the non-working samples off the catalog.

Lin

On Fri, Jun 27, 2008 at 3:26 PM,  <[EMAIL PROTECTED]> wrote:
> Author: jbohn
> Date: Fri Jun 27 12:26:10 2008
> New Revision: 672364
>
> URL: http://svn.apache.org/viewvc?rev=672364&view=rev
> Log:
> update plugin catalog for 2.1.1 to remove 2.1-SNAPSHOT samples that are not 
> yet updated for Geronimo 2.1.1
>
> Modified:
>geronimo/site/trunk/docs/plugins/geronimo-2.1.1/geronimo-plugins.xml
>
> Modified: geronimo/site/trunk/docs/plugins/geronimo-2.1.1/geronimo-plugins.xml
> URL: 
> http://svn.apache.org/viewvc/geronimo/site/trunk/docs/plugins/geronimo-2.1.1/geronimo-plugins.xml?rev=672364&r1=672363&r2=672364&view=diff
> ==
> --- geronimo/site/trunk/docs/plugins/geronimo-2.1.1/geronimo-plugins.xml 
> (original)
> +++ geronimo/site/trunk/docs/plugins/geronimo-2.1.1/geronimo-plugins.xml Fri 
> Jun 27 12:26:10 2008
> @@ -7170,357 +7170,6 @@
> 
> 
> 
> -Geronimo Configs :: LDAP Sample Security Realm
> -Example
> -A sample security realm pointing to an embedded Apache 
> Directory
> -LDAP server.  This is normally used with the LDAP Example Web 
> Application,
> -which has instructions for setting up the LDAP server and screens to 
> test
> -logins.  You don't need this plugin in order to create LDAP security 
> realms,
> -this is just a sample.
> -http://www.apache.org
> -Apache Software Foundation
> -The Apache Software License, Version 
> 2.0
> -
> -
> -org.apache.geronimo.configs
> -ldap-sample-app-realm
> -2.1-SNAPSHOT
> -car
> -
> -2.1.1
> -1.5
> -
> -org.apache.geronimo.framework
> -server-security-config
> -2.1.1
> -car
> -
> -
> http://repo1.maven.org/maven2/
> -
> http://people.apache.org/repo/m2-snapshot-repository/
> -
> http://people.apache.org/repo/m2-incubating-repository/
> -
> -
> -
> -Geronimo Configs :: LDAP Sample for Jetty
> -Example
> -A web application that walks you through configuring 
> the sample
> -data in the embedded Apache Directory LDAP server, and then tests 
> logins
> -with a demonstration security realm configured for that LDAP server.
> -The LDAP Example web application be found via HTTP at /LDAP_Sample/ 
> after
> -the plugin is installed.
> -http://www.apache.org
> -Apache Software Foundation
> -The Apache Software License, Version 
> 2.0
> -
> -
> -org.apache.geronimo.configs
> -ldap-sample-app-jetty
> -2.1-SNAPSHOT
> -car
> -
> -2.1.1
> -1.5
> -
> -
> -org.apache.geronimo.configs
> -jetty6
> -
> -Web Container
> -This version of the application works with the 
> Geronimo/Jetty distribution.
> -It is not intended to run in the 
> Geronimo/Tomcat distribution.
> -There is a separate version of the 
> application that works with Tomcat.
> -Please install the version appropriate 
> to your Geronimo distribution.
> -
> -
> -org.apache.geronimo.samples
> -ldap-sample-app-war
> -2.1-SNAPSHOT
> -war
> -
> -
> -org.apache.geronimo.configs
> -ldap-sample-app-realm
> -2.1-SNAPSHOT
> -car
> -
> -
> -org.apache.geronimo.configs
> -jasper
> -2.1.1
> -car
> -
> -
> -org.apache.geronimo.configs
> -jetty6
> -2.1.1
> -car
> -
> -
> http://repo1.maven.org/maven2/
> -
> http://people.apache.org/repo/m2-snapshot-repository/
> -
> http://people.apache.org/repo/m2-incubating-repository/
> -
> -
> -
> -Geronimo Configs :: LDAP Sample for Tomcat
> -Example
> -A web application that walks you through configuring 
> the sample
> -data in the embedded Apache Directory LDAP server, and then tests 
> logins
> -with a demonstration security realm configured for that LDAP server.
> -The LDAP Example web application be found via HTTP at /LDAP_Sample/ 
> after
> -the plugin is installed.
> -http://www.apache.org
> -

Re: making plugins (plugins portlet) more visible in the console


Donald Woods wrote:
Yep, maybe we need to move the samples back into the server tree (but 
under their own /samples subdir) for 2.2.  That would also allow us to 
create a samples-testsuite to verify they work... :-)


I removed the 3 remaining samples from the 2.1.1 catalog.

Joe



Joe Bohn wrote:

Donald Woods wrote:
OK, guess I selected a bad plugin to install from the list and 
assumed that they were all bad


I downloaded and installed a clean 
geronimo-tomcat6-javaee5-2.1.1-bin.tar.gz


Manually added the 2.1.1 plugin repo - 
http://geronimo.apache.org/plugins/geronimo-2.1.1/


Selected the "Geronimo Plugins :: Monitoring Agent (JMX)" and it 
installed fine.


If you select the "Geronimo Configs :: Servlet Examples for Tomcat 
2.1-SNAPSHOT - Example" which shows up in the list, it will FAIL with 
- "A problem has occured:
org.apache.geronimo.kernel.repository.MissingDependencyException: 
Plugin is not installable on Geronimo 2.1.1 Missing dependency: 
org.apache.geronimo.samples/servlet-examples-tomcat/2.1-SNAPSHOT/car"


Guess we need to remove that plugin once we have the Samples updated 
and released for 2.1.


Ahh ... I think that when I was updating the catalog for 2.1.1 I left 
the LDAP Sample Realm, LDAP Sample, JSP Example, and Servlet Example 
in there because of the references from the welcome page.  Since they 
can not be installed even with the entries I think we should just go 
ahead and remove them completely from the 2.1.1 catalog.  This won't 
prevent people from trying via the welcome page but it will prevent 
any attempts from the catalog (if they take the time to switch to the 
2.1.1 catalog that is).  Is there any reason to keep these samples in 
the 2.1.1 catalog for now that I'm missing?  When/if we get samples 
deployed that can be installed on 2.1.1 we can add the updated samples 
back into the catalog.


This would really be a whole lot more manageable (and correct) if we 
were to merge the samples back into the server and release them 
concurrently.  I know several folks disagree but the current 
separation has not yet been successful.


Joe





-Donald



Joe Bohn wrote:

Lin Sun wrote:

Joe, I ran some test against the 2.1.1 plugin repo 2 weeks ago and I
could not install the sample plugins I tried - forgot the error/prob
(think I tried the servlet and jsp samples).

Lin


There is 1 problem here and a few misunderstandings based upon that 
problem:


Problem:
- The default for the plugin repo for Geronimo 2.1.1 is actually the 
plugin repo for 2.1.  In order to see the Geronimo 2.1.1 plugin repo 
you must manually add the repository.  See this thread for a 
discussion of this issue: 
http://www.nabble.com/plugin-repository-for-2.1.1-td16990905s134.html



The not yet released samples (2.1-SNAPSHOT) are tied to Geronimo 2.1 
and not Geronimo 2.1.1.  This is why I have been interested in 
getting samples released for 2.1 and 2.1.1.  The 2.1-SNAPSHOT 
samples appear in the 2.1 repository but not the 2.1.1 repository.  
So, if you reference the 2.1.1 repository you will not see the 
samples listed at all and not encounter a problem on the install. Of 
course, that is tricky to do since we show you the wrong repository 
by default in 2.1.1.


So, I think what happened was that you accessed the 2.1 repository 
from a 2.1.1 server and attempted to install one of the sample 
plugins from there.


There is one more problem that you or others may hit regarding 
attempts to install samples in 2.1.1 at this time.  The servlet, 
jsp, and ldap samples are referenced directly from default/welcome 
servlet (/) and can optionally be installed from there.  An attempt 
to install them from this location will also fail given that it is 
referencing the same incorrect, default plugin repo for 2.1.


To summarize ... the 2.1.1 repo is not broken AFAIK (if it is broken 
then we can easily fix it).  What is broken is that 2.1.1 references 
the wrong plugin repo by default.  That problem will be fixed when 
we release 2.1.2.


Joe



On Fri, Jun 27, 2008 at 9:09 AM, Joe Bohn <[EMAIL PROTECTED]> 
wrote:

Donald Woods wrote:
Yeah, but until plugins built on earlier releases (like 2.1) work 
on later
maintenance updates (like 2.1.1 and 2.1.2) and we fix the 
currently broken

2.1.1 plugin repo, I don't think we really want to over-hype this
feature
By "the currently broken 2.1.1 plugin repo" do you just mean the 
fact that
in G 2.1.1 the console defaults to the 2.1 plugin repo rather than 
the 2.1.1
plugin repo?  The 2.1.1 plugin repo itself is not broken AFAIK and 
should

work correctly if you access it.

Joe




-Donald


Jarek Gawor wrote:

Yeah, that's a good point. But there are some things we could do
without the collapsible tree, for example, ensure that the debug 
views

always show up on the bottom, or combine "Information" and "Java
System Info" into one portlet.

Anyway, I proposed this change becuase I feel like we should make
plugins and plugins infrastructure much more visi

[BUILD] trunk: Failed for Revision: 672358

2008-06-27 Thread gawor

Geronimo Revision: 672358 built with tests included
 
See the full build-1500.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080627/build-1500.log
 
 
See the unit test reports at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080627/unit-test-reports
 
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 26 source files to 
/home/geronimo/geronimo/trunk/plugins/console/console-core/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] Surefire report directory: 
/home/geronimo/geronimo/trunk/plugins/console/console-core/target/surefire-reports

---
 T E S T S
---
There are no tests to run.

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

[INFO] [jar:jar]
[INFO] Building jar: 
/home/geronimo/geronimo/trunk/plugins/console/console-core/target/console-core-2.2-SNAPSHOT.jar
[INFO] [ianal:verify-legal-files {execution: default}]
[INFO] Checking legal files in: console-core-2.2-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing 
/home/geronimo/geronimo/trunk/plugins/console/console-core/target/console-core-2.2-SNAPSHOT.jar
 to 
/home/geronimo/.m2/repository/org/apache/geronimo/plugins/console-core/2.2-SNAPSHOT/console-core-2.2-SNAPSHOT.jar
[INFO] 
[INFO] Building Geronimo Plugins, ActiveMQ :: Portlets
[INFO]task-segment: [install]
[INFO] 
[INFO] snapshot org.codehaus.mojo.jspc:jspc-maven-plugin:2.0-alpha-2-SNAPSHOT: 
checking for updates from apache-snapshots
[INFO] snapshot org.codehaus.mojo.jspc:jspc-maven-plugin:2.0-alpha-2-SNAPSHOT: 
checking for updates from codehaus-snapshots
[INFO] snapshot org.codehaus.mojo.jspc:jspc-maven-plugin:2.0-alpha-2-SNAPSHOT: 
checking for updates from apache.snapshots
Downloading: 
http://snapshots.repository.codehaus.org/org/codehaus/mojo/jspc/jspc-maven-plugin/2.0-alpha-2-SNAPSHOT/jspc-maven-plugin-2.0-alpha-2-20080504.150315-3.pom
3K downloaded
[INFO] snapshot org.codehaus.mojo.jspc:jspc:2.0-alpha-2-SNAPSHOT: checking for 
updates from apache-snapshots
[INFO] snapshot org.codehaus.mojo.jspc:jspc:2.0-alpha-2-SNAPSHOT: checking for 
updates from codehaus-snapshots
[INFO] snapshot org.codehaus.mojo.jspc:jspc:2.0-alpha-2-SNAPSHOT: checking for 
updates from apache.snapshots
Downloading: 
http://snapshots.repository.codehaus.org/org/codehaus/mojo/jspc/jspc/2.0-alpha-2-SNAPSHOT/jspc-2.0-alpha-2-20080504.150315-4.pom
17K downloaded
Downloading: 
http://snapshots.repository.codehaus.org/org/codehaus/mojo/jspc/jspc-maven-plugin/2.0-alpha-2-SNAPSHOT/jspc-maven-plugin-2.0-alpha-2-20080504.150315-3.jar
32K downloaded
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 41 source files to 
/home/geronimo/geronimo/trunk/plugins/activemq/activemq-portlets/target/classes
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure

/home/geronimo/geronimo/trunk/plugins/activemq/activemq-portlets/src/main/java/org/apache/geronimo/console/jmsmanager/helper/JMSMessageHelperFactory.java:[59,19]
 cannot find symbol
symbol  : method error(java.lang.IllegalAccessException)
location: interface org.slf4j.Logger

/home/geronimo/geronimo/trunk/plugins/activemq/activemq-portlets/src/main/java/org/apache/geronimo/console/jmsmanager/helper/JMSMessageHelperFactory.java:[61,19]
 cannot find symbol
symbol  : method error(java.lang.InstantiationException)
location: interface org.slf4j.Logger

/home/geronimo/geronimo/trunk/plugins/activemq/activemq-portlets/src/main/java/org/apache/geronimo/console/jmsmanager/helper/JMSMessageHelperFactory.java:[63,19]
 cannot find symbol
symbol  : method error(java.lang.ClassNotFoundException)
location: interface org.slf4j.Logger

/home/geronimo/geronimo/trunk/plugins/activemq/activemq-portlets/src/main/java/org/apache/geronimo/console/jmsmanager/helper/AmqJMSMessageHelper.java:[130,15]
 cannot find symbol
symbol  : method error(java.lang.Exception)
location: interface org.slf4j.Logger


[INFO] 
[INFO] Trace
org.apache.maven.BuildFailureException: Compilation failure
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:579)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle

Re: Reducing the dojo footprint in Geronimo

2008-06-27 Thread Jay D. McHugh

I have thought about this a lot (since I have become very accustomed to 
having Dojo 'just be there').


And the consensus (or at least what appears to be becoming the 
consensus) of only including what is needed for the admin console is 
probably the best idea.  Especially since the installed size of Dojo has 
ballooned from around 6Meg to around 22Meg.


Along with this, we should probably also drop the 'dojo-legacy' plugin 
(as soon as the work to upgrade to using the 1.1.x version of Dojo is 
completed).  And we should provide a plugin for the full Dojo install. 
It is easy enough to provide and will help those who have gotten used to 
having Dojo 'just be there' - upgrade with a minimum of pain.


Jay

Donald Woods wrote:
Sounds like the right solution, given that would allow our console to 
upgrade at a slower pace and would allow users to choose their own level...


Other option, is to drop the /dojo webapp in 2.2, only ship what we need 
in the console and let users package the Dojo level and features they 
need within their own apps (which is more portable across different 
servers anyway)



-Donald


Kevan Miller wrote:


On Jun 27, 2008, at 11:00 AM, Shrey Banga wrote:



As for the including the rest of DojoX, since it a significant part 
of the reducing effort.  Would it make sense to build a custom js for 
monitoring, remove the rest of DojoX and if the development starts 
shifting to a real need for DojoX to make a decision to bring it back 
in the future?


I think that makes perfect sense- not only will this do the part in 
reducing the dojo footprint, it'll also be useful as an example to 
how dojo should be used optimally in deployment. Another desirable 
side-effect would be reduced load times in the monitoring 
application, although currently that is not an issue.


I'm starting to think that our server should deliver dojo support that 
is targeted to the requirements of the admin console.


For general dojo support, we could provide an installable dojo plugin 
that's equivalent to the /dojo support we currently provide...


--kevan

Re: making plugins (plugins portlet) more visible in the console

Yep, maybe we need to move the samples back into the server tree (but 
under their own /samples subdir) for 2.2.  That would also allow us to 
create a samples-testsuite to verify they work... :-)



-Donald


Joe Bohn wrote:

Donald Woods wrote:
OK, guess I selected a bad plugin to install from the list and assumed 
that they were all bad


I downloaded and installed a clean 
geronimo-tomcat6-javaee5-2.1.1-bin.tar.gz


Manually added the 2.1.1 plugin repo - 
http://geronimo.apache.org/plugins/geronimo-2.1.1/


Selected the "Geronimo Plugins :: Monitoring Agent (JMX)" and it 
installed fine.


If you select the "Geronimo Configs :: Servlet Examples for Tomcat 
2.1-SNAPSHOT - Example" which shows up in the list, it will FAIL with 
- "A problem has occured:
org.apache.geronimo.kernel.repository.MissingDependencyException: 
Plugin is not installable on Geronimo 2.1.1 Missing dependency: 
org.apache.geronimo.samples/servlet-examples-tomcat/2.1-SNAPSHOT/car"


Guess we need to remove that plugin once we have the Samples updated 
and released for 2.1.


Ahh ... I think that when I was updating the catalog for 2.1.1 I left 
the LDAP Sample Realm, LDAP Sample, JSP Example, and Servlet Example in 
there because of the references from the welcome page.  Since they can 
not be installed even with the entries I think we should just go ahead 
and remove them completely from the 2.1.1 catalog.  This won't prevent 
people from trying via the welcome page but it will prevent any attempts 
from the catalog (if they take the time to switch to the 2.1.1 catalog 
that is).  Is there any reason to keep these samples in the 2.1.1 
catalog for now that I'm missing?  When/if we get samples deployed that 
can be installed on 2.1.1 we can add the updated samples back into the 
catalog.


This would really be a whole lot more manageable (and correct) if we 
were to merge the samples back into the server and release them 
concurrently.  I know several folks disagree but the current separation 
has not yet been successful.


Joe





-Donald



Joe Bohn wrote:

Lin Sun wrote:

Joe, I ran some test against the 2.1.1 plugin repo 2 weeks ago and I
could not install the sample plugins I tried - forgot the error/prob
(think I tried the servlet and jsp samples).

Lin


There is 1 problem here and a few misunderstandings based upon that 
problem:


Problem:
- The default for the plugin repo for Geronimo 2.1.1 is actually the 
plugin repo for 2.1.  In order to see the Geronimo 2.1.1 plugin repo 
you must manually add the repository.  See this thread for a 
discussion of this issue: 
http://www.nabble.com/plugin-repository-for-2.1.1-td16990905s134.html



The not yet released samples (2.1-SNAPSHOT) are tied to Geronimo 2.1 
and not Geronimo 2.1.1.  This is why I have been interested in 
getting samples released for 2.1 and 2.1.1.  The 2.1-SNAPSHOT samples 
appear in the 2.1 repository but not the 2.1.1 repository.  So, if 
you reference the 2.1.1 repository you will not see the samples 
listed at all and not encounter a problem on the install. Of course, 
that is tricky to do since we show you the wrong repository by 
default in 2.1.1.


So, I think what happened was that you accessed the 2.1 repository 
from a 2.1.1 server and attempted to install one of the sample 
plugins from there.


There is one more problem that you or others may hit regarding 
attempts to install samples in 2.1.1 at this time.  The servlet, jsp, 
and ldap samples are referenced directly from default/welcome servlet 
(/) and can optionally be installed from there.  An attempt to 
install them from this location will also fail given that it is 
referencing the same incorrect, default plugin repo for 2.1.


To summarize ... the 2.1.1 repo is not broken AFAIK (if it is broken 
then we can easily fix it).  What is broken is that 2.1.1 references 
the wrong plugin repo by default.  That problem will be fixed when we 
release 2.1.2.


Joe



On Fri, Jun 27, 2008 at 9:09 AM, Joe Bohn <[EMAIL PROTECTED]> 
wrote:

Donald Woods wrote:
Yeah, but until plugins built on earlier releases (like 2.1) work 
on later
maintenance updates (like 2.1.1 and 2.1.2) and we fix the 
currently broken

2.1.1 plugin repo, I don't think we really want to over-hype this
feature
By "the currently broken 2.1.1 plugin repo" do you just mean the 
fact that
in G 2.1.1 the console defaults to the 2.1 plugin repo rather than 
the 2.1.1
plugin repo?  The 2.1.1 plugin repo itself is not broken AFAIK and 
should

work correctly if you access it.

Joe




-Donald


Jarek Gawor wrote:

Yeah, that's a good point. But there are some things we could do
without the collapsible tree, for example, ensure that the debug 
views

always show up on the bottom, or combine "Information" and "Java
System Info" into one portlet.

Anyway, I proposed this change becuase I feel like we should make
plugins and plugins infrastructure much more visible. Not only in 
the

console but everywhere else such as the website, docu

[jira] Created: (GERONIMO-4169) JAX-WS web services not discovered with patrial web.xml file

2008-06-27 Thread Jarek Gawor (JIRA)

JAX-WS web services not discovered with patrial web.xml file


 Key: GERONIMO-4169
 URL: https://issues.apache.org/jira/browse/GERONIMO-4169
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: webservices
Affects Versions: 2.0.x, 2.1.2, 2.2
Reporter: Jarek Gawor
Assignee: Jarek Gawor


After re-reading the spec and testing with the RI, it looks like we should be 
discovering JAX-WS web services even if a partial web.xml is supplied. Right 
now, we only discover the JAX-WS web services if there is no web.xml provided. 





-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: making plugins (plugins portlet) more visible in the console


Lin Sun wrote:

I did the same, I added the 2.1.1 plugin repo manually and tried the
servlet and jsp samples for tomcat, but neither worked.

Joe, Can we still make changes to the 2.1.1 plugin repo?  I think this
"Missing dependency" is caused by an incorrect configuration in the
project's pom.xml.


We can update the catalog anytime.  I think it's best to remove the 
samples that I referenced in my response to Donald.




Lin

On Fri, Jun 27, 2008 at 2:50 PM, Donald Woods <[EMAIL PROTECTED]> wrote:

OK, guess I selected a bad plugin to install from the list and assumed that
they were all bad

I downloaded and installed a clean geronimo-tomcat6-javaee5-2.1.1-bin.tar.gz

Manually added the 2.1.1 plugin repo -
http://geronimo.apache.org/plugins/geronimo-2.1.1/

Selected the "Geronimo Plugins :: Monitoring Agent (JMX)" and it installed
fine.

If you select the "Geronimo Configs :: Servlet Examples for Tomcat
2.1-SNAPSHOT - Example" which shows up in the list, it will FAIL with - "A
problem has occured:
org.apache.geronimo.kernel.repository.MissingDependencyException: Plugin is
not installable on Geronimo 2.1.1 Missing dependency:
org.apache.geronimo.samples/servlet-examples-tomcat/2.1-SNAPSHOT/car"

Guess we need to remove that plugin once we have the Samples updated and
released for 2.1.


-Donald



Joe Bohn wrote:

Lin Sun wrote:

Joe, I ran some test against the 2.1.1 plugin repo 2 weeks ago and I
could not install the sample plugins I tried - forgot the error/prob
(think I tried the servlet and jsp samples).

Lin

There is 1 problem here and a few misunderstandings based upon that
problem:

Problem:
- The default for the plugin repo for Geronimo 2.1.1 is actually the
plugin repo for 2.1.  In order to see the Geronimo 2.1.1 plugin repo you
must manually add the repository.  See this thread for a discussion of this
issue: http://www.nabble.com/plugin-repository-for-2.1.1-td16990905s134.html


The not yet released samples (2.1-SNAPSHOT) are tied to Geronimo 2.1 and
not Geronimo 2.1.1.  This is why I have been interested in getting samples
released for 2.1 and 2.1.1.  The 2.1-SNAPSHOT samples appear in the 2.1
repository but not the 2.1.1 repository.  So, if you reference the 2.1.1
repository you will not see the samples listed at all and not encounter a
problem on the install. Of course, that is tricky to do since we show you
the wrong repository by default in 2.1.1.

So, I think what happened was that you accessed the 2.1 repository from a
2.1.1 server and attempted to install one of the sample plugins from there.

There is one more problem that you or others may hit regarding attempts to
install samples in 2.1.1 at this time.  The servlet, jsp, and ldap samples
are referenced directly from default/welcome servlet (/) and can optionally
be installed from there.  An attempt to install them from this location will
also fail given that it is referencing the same incorrect, default plugin
repo for 2.1.

To summarize ... the 2.1.1 repo is not broken AFAIK (if it is broken then
we can easily fix it).  What is broken is that 2.1.1 references the wrong
plugin repo by default.  That problem will be fixed when we release 2.1.2.

Joe


On Fri, Jun 27, 2008 at 9:09 AM, Joe Bohn <[EMAIL PROTECTED]> wrote:

Donald Woods wrote:

Yeah, but until plugins built on earlier releases (like 2.1) work on
later
maintenance updates (like 2.1.1 and 2.1.2) and we fix the currently
broken
2.1.1 plugin repo, I don't think we really want to over-hype this
feature

By "the currently broken 2.1.1 plugin repo" do you just mean the fact
that
in G 2.1.1 the console defaults to the 2.1 plugin repo rather than the
2.1.1
plugin repo?  The 2.1.1 plugin repo itself is not broken AFAIK and
should
work correctly if you access it.

Joe



-Donald


Jarek Gawor wrote:

Yeah, that's a good point. But there are some things we could do
without the collapsible tree, for example, ensure that the debug views
always show up on the bottom, or combine "Information" and "Java
System Info" into one portlet.

Anyway, I proposed this change becuase I feel like we should make
plugins and plugins infrastructure much more visible. Not only in the
console but everywhere else such as the website, documentation, etc.

Jarek

On Thu, Jun 26, 2008 at 4:54 PM, Donald Woods <[EMAIL PROTECTED]>
wrote:

I'd rather keep Plugins under applications.

As Joe pointed out, the navigational tree is already taking up too
much
vertical space now for lower resolution displays.  Maybe if we ever
have
the
collapsible tree again, then we could rearrange/regroup the
portlets...


-Donald



Jarek Gawor wrote:

Hey,

Right now, the plugins portlet is not all that visible in the admin
console (it's under Applications / Plugins). I think it would be
great
to make it more visible by creating a new "Plugins" section with
"Install", "Export", and "Assemble Server" subsections. I already
created three separate portlets for these plugin operations so
rearranging things visually should b

Re: making plugins (plugins portlet) more visible in the console


Donald Woods wrote:
OK, guess I selected a bad plugin to install from the list and assumed 
that they were all bad


I downloaded and installed a clean 
geronimo-tomcat6-javaee5-2.1.1-bin.tar.gz


Manually added the 2.1.1 plugin repo - 
http://geronimo.apache.org/plugins/geronimo-2.1.1/


Selected the "Geronimo Plugins :: Monitoring Agent (JMX)" and it 
installed fine.


If you select the "Geronimo Configs :: Servlet Examples for Tomcat 
2.1-SNAPSHOT - Example" which shows up in the list, it will FAIL with - 
"A problem has occured:
org.apache.geronimo.kernel.repository.MissingDependencyException: Plugin 
is not installable on Geronimo 2.1.1 Missing dependency: 
org.apache.geronimo.samples/servlet-examples-tomcat/2.1-SNAPSHOT/car"


Guess we need to remove that plugin once we have the Samples updated and 
released for 2.1.


Ahh ... I think that when I was updating the catalog for 2.1.1 I left 
the LDAP Sample Realm, LDAP Sample, JSP Example, and Servlet Example in 
there because of the references from the welcome page.  Since they can 
not be installed even with the entries I think we should just go ahead 
and remove them completely from the 2.1.1 catalog.  This won't prevent 
people from trying via the welcome page but it will prevent any attempts 
from the catalog (if they take the time to switch to the 2.1.1 catalog 
that is).  Is there any reason to keep these samples in the 2.1.1 
catalog for now that I'm missing?  When/if we get samples deployed that 
can be installed on 2.1.1 we can add the updated samples back into the 
catalog.


This would really be a whole lot more manageable (and correct) if we 
were to merge the samples back into the server and release them 
concurrently.  I know several folks disagree but the current separation 
has not yet been successful.


Joe





-Donald



Joe Bohn wrote:

Lin Sun wrote:

Joe, I ran some test against the 2.1.1 plugin repo 2 weeks ago and I
could not install the sample plugins I tried - forgot the error/prob
(think I tried the servlet and jsp samples).

Lin


There is 1 problem here and a few misunderstandings based upon that 
problem:


Problem:
- The default for the plugin repo for Geronimo 2.1.1 is actually the 
plugin repo for 2.1.  In order to see the Geronimo 2.1.1 plugin repo 
you must manually add the repository.  See this thread for a 
discussion of this issue: 
http://www.nabble.com/plugin-repository-for-2.1.1-td16990905s134.html



The not yet released samples (2.1-SNAPSHOT) are tied to Geronimo 2.1 
and not Geronimo 2.1.1.  This is why I have been interested in getting 
samples released for 2.1 and 2.1.1.  The 2.1-SNAPSHOT samples appear 
in the 2.1 repository but not the 2.1.1 repository.  So, if you 
reference the 2.1.1 repository you will not see the samples listed at 
all and not encounter a problem on the install. Of course, that is 
tricky to do since we show you the wrong repository by default in 2.1.1.


So, I think what happened was that you accessed the 2.1 repository 
from a 2.1.1 server and attempted to install one of the sample plugins 
from there.


There is one more problem that you or others may hit regarding 
attempts to install samples in 2.1.1 at this time.  The servlet, jsp, 
and ldap samples are referenced directly from default/welcome servlet 
(/) and can optionally be installed from there.  An attempt to install 
them from this location will also fail given that it is referencing 
the same incorrect, default plugin repo for 2.1.


To summarize ... the 2.1.1 repo is not broken AFAIK (if it is broken 
then we can easily fix it).  What is broken is that 2.1.1 references 
the wrong plugin repo by default.  That problem will be fixed when we 
release 2.1.2.


Joe



On Fri, Jun 27, 2008 at 9:09 AM, Joe Bohn <[EMAIL PROTECTED]> 
wrote:

Donald Woods wrote:
Yeah, but until plugins built on earlier releases (like 2.1) work 
on later
maintenance updates (like 2.1.1 and 2.1.2) and we fix the currently 
broken

2.1.1 plugin repo, I don't think we really want to over-hype this
feature
By "the currently broken 2.1.1 plugin repo" do you just mean the 
fact that
in G 2.1.1 the console defaults to the 2.1 plugin repo rather than 
the 2.1.1
plugin repo?  The 2.1.1 plugin repo itself is not broken AFAIK and 
should

work correctly if you access it.

Joe




-Donald


Jarek Gawor wrote:

Yeah, that's a good point. But there are some things we could do
without the collapsible tree, for example, ensure that the debug 
views

always show up on the bottom, or combine "Information" and "Java
System Info" into one portlet.

Anyway, I proposed this change becuase I feel like we should make
plugins and plugins infrastructure much more visible. Not only in the
console but everywhere else such as the website, documentation, etc.

Jarek

On Thu, Jun 26, 2008 at 4:54 PM, Donald Woods <[EMAIL PROTECTED]> 
wrote:

I'd rather keep Plugins under applications.

As Joe pointed out, the navigational tree is already taking up 
too much
vertical spa

Re: making plugins (plugins portlet) more visible in the console

2008-06-27 Thread Lin Sun

I did the same, I added the 2.1.1 plugin repo manually and tried the
servlet and jsp samples for tomcat, but neither worked.

Joe, Can we still make changes to the 2.1.1 plugin repo?  I think this
"Missing dependency" is caused by an incorrect configuration in the
project's pom.xml.

Lin

On Fri, Jun 27, 2008 at 2:50 PM, Donald Woods <[EMAIL PROTECTED]> wrote:
> OK, guess I selected a bad plugin to install from the list and assumed that
> they were all bad
>
> I downloaded and installed a clean geronimo-tomcat6-javaee5-2.1.1-bin.tar.gz
>
> Manually added the 2.1.1 plugin repo -
> http://geronimo.apache.org/plugins/geronimo-2.1.1/
>
> Selected the "Geronimo Plugins :: Monitoring Agent (JMX)" and it installed
> fine.
>
> If you select the "Geronimo Configs :: Servlet Examples for Tomcat
> 2.1-SNAPSHOT - Example" which shows up in the list, it will FAIL with - "A
> problem has occured:
> org.apache.geronimo.kernel.repository.MissingDependencyException: Plugin is
> not installable on Geronimo 2.1.1 Missing dependency:
> org.apache.geronimo.samples/servlet-examples-tomcat/2.1-SNAPSHOT/car"
>
> Guess we need to remove that plugin once we have the Samples updated and
> released for 2.1.
>
>
> -Donald
>
>
>
> Joe Bohn wrote:
>>
>> Lin Sun wrote:
>>>
>>> Joe, I ran some test against the 2.1.1 plugin repo 2 weeks ago and I
>>> could not install the sample plugins I tried - forgot the error/prob
>>> (think I tried the servlet and jsp samples).
>>>
>>> Lin
>>
>> There is 1 problem here and a few misunderstandings based upon that
>> problem:
>>
>> Problem:
>> - The default for the plugin repo for Geronimo 2.1.1 is actually the
>> plugin repo for 2.1.  In order to see the Geronimo 2.1.1 plugin repo you
>> must manually add the repository.  See this thread for a discussion of this
>> issue: http://www.nabble.com/plugin-repository-for-2.1.1-td16990905s134.html
>>
>>
>> The not yet released samples (2.1-SNAPSHOT) are tied to Geronimo 2.1 and
>> not Geronimo 2.1.1.  This is why I have been interested in getting samples
>> released for 2.1 and 2.1.1.  The 2.1-SNAPSHOT samples appear in the 2.1
>> repository but not the 2.1.1 repository.  So, if you reference the 2.1.1
>> repository you will not see the samples listed at all and not encounter a
>> problem on the install. Of course, that is tricky to do since we show you
>> the wrong repository by default in 2.1.1.
>>
>> So, I think what happened was that you accessed the 2.1 repository from a
>> 2.1.1 server and attempted to install one of the sample plugins from there.
>>
>> There is one more problem that you or others may hit regarding attempts to
>> install samples in 2.1.1 at this time.  The servlet, jsp, and ldap samples
>> are referenced directly from default/welcome servlet (/) and can optionally
>> be installed from there.  An attempt to install them from this location will
>> also fail given that it is referencing the same incorrect, default plugin
>> repo for 2.1.
>>
>> To summarize ... the 2.1.1 repo is not broken AFAIK (if it is broken then
>> we can easily fix it).  What is broken is that 2.1.1 references the wrong
>> plugin repo by default.  That problem will be fixed when we release 2.1.2.
>>
>> Joe
>>
>>>
>>> On Fri, Jun 27, 2008 at 9:09 AM, Joe Bohn <[EMAIL PROTECTED]> wrote:

 Donald Woods wrote:
>
> Yeah, but until plugins built on earlier releases (like 2.1) work on
> later
> maintenance updates (like 2.1.1 and 2.1.2) and we fix the currently
> broken
> 2.1.1 plugin repo, I don't think we really want to over-hype this
> feature

 By "the currently broken 2.1.1 plugin repo" do you just mean the fact
 that
 in G 2.1.1 the console defaults to the 2.1 plugin repo rather than the
 2.1.1
 plugin repo?  The 2.1.1 plugin repo itself is not broken AFAIK and
 should
 work correctly if you access it.

 Joe


>
> -Donald
>
>
> Jarek Gawor wrote:
>>
>> Yeah, that's a good point. But there are some things we could do
>> without the collapsible tree, for example, ensure that the debug views
>> always show up on the bottom, or combine "Information" and "Java
>> System Info" into one portlet.
>>
>> Anyway, I proposed this change becuase I feel like we should make
>> plugins and plugins infrastructure much more visible. Not only in the
>> console but everywhere else such as the website, documentation, etc.
>>
>> Jarek
>>
>> On Thu, Jun 26, 2008 at 4:54 PM, Donald Woods <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> I'd rather keep Plugins under applications.
>>>
>>> As Joe pointed out, the navigational tree is already taking up too
>>> much
>>> vertical space now for lower resolution displays.  Maybe if we ever
>>> have
>>> the
>>> collapsible tree again, then we could rearrange/regroup the
>>> portlets...
>>>
>>>
>>> -Donald
>>>
>>>
>>>
>>> Jarek Gaw

[jira] Closed: (GERONIMO-2758) Upgrade to Howl 1.0.2


 [ 
https://issues.apache.org/jira/browse/GERONIMO-2758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donald Woods closed GERONIMO-2758.
--

Resolution: Won't Fix

Closing, as Howl has never published their 1.0.2 release to the public maven 
repos
Will open a new JIRA if they ever do.



> Upgrade to Howl 1.0.2
> -
>
> Key: GERONIMO-2758
> URL: https://issues.apache.org/jira/browse/GERONIMO-2758
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: dependencies
>Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.x, 2.1
>Reporter: Donald Woods
>Assignee: Donald Woods
>Priority: Minor
> Fix For: Wish List
>
>
> Howl 1.0.2 was released on 2007-01-02, but has not been published to the m2 
> repo yet.
> Will attach a patch once the jar is available on the default m2 repo.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GERONIMO-2028) Plugin export errors don't stop process, but cause it to fail much later


 [ 
https://issues.apache.org/jira/browse/GERONIMO-2028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donald Woods closed GERONIMO-2028.
--

Resolution: Cannot Reproduce

This seems to have been fixed in 2.1.1 and 2.2.  Please reopen if you have a 
concrete scenario that reproduces the failure on a later server version.

> Plugin export errors don't stop process, but cause it to fail much later
> 
>
> Key: GERONIMO-2028
> URL: https://issues.apache.org/jira/browse/GERONIMO-2028
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Plugins
>Affects Versions: 1.1
>Reporter: Aaron Mulder
>Assignee: Donald Woods
>
> When exporting a plugin, if there are any errors loading the existing XML 
> document, the console goes on to the export screen and just renders it 
> entirely empty (including the module ID).  It should instead produce an error 
> message.
> To reproduce, edit 
> repository/geronimo/welcome-jetty/1.1-SNAPSHOT/welcome-jetty-1.1-SNAPSHOT.car/META-INF/geronimo-plugin.xml
>  to make it invalid, go to the console, select the plugins screen, pick 
> geronimo/welcome-jetty/* as the configuration to export, and click the export 
> button.  You presently get a screen with a bunch of blank text fields, and 
> should instead get an error message / page.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: making plugins (plugins portlet) more visible in the console


Yep, that sounds ike a better split.
And agree to only making console reorg changes like this in trunk.


-Donald


Kevan Miller wrote:


On Jun 25, 2008, at 3:04 PM, Jarek Gawor wrote:


Hey,

Right now, the plugins portlet is not all that visible in the admin
console (it's under Applications / Plugins). I think it would be great
to make it more visible by creating a new "Plugins" section with
"Install", "Export", and "Assemble Server" subsections. I already
created three separate portlets for these plugin operations so
rearranging things visually should be easy.


Adding to the fray... :-P

I'm not so sure that "Assemble Server" logically belongs with the 
"Plugin Install" and "Plugin Export" functions. Personally, I think it's 
a bit hard to find under "Plugins". I'm fine having "Plugin Install" and 
"Plugin Export" under Applications.


Are we discussing this for branches/2.1 or trunk? I don't think we 
should be making too many 2.1 changes. I think we could look at a good 
re-org on trunk (if there's interest).


--kevan



smime.p7s
Description: S/MIME Cryptographic Signature

Re: making plugins (plugins portlet) more visible in the console

OK, guess I selected a bad plugin to install from the list and assumed 
that they were all bad


I downloaded and installed a clean geronimo-tomcat6-javaee5-2.1.1-bin.tar.gz

Manually added the 2.1.1 plugin repo - 
http://geronimo.apache.org/plugins/geronimo-2.1.1/


Selected the "Geronimo Plugins :: Monitoring Agent (JMX)" and it 
installed fine.


If you select the "Geronimo Configs :: Servlet Examples for Tomcat 
2.1-SNAPSHOT - Example" which shows up in the list, it will FAIL with - 
"A problem has occured:
org.apache.geronimo.kernel.repository.MissingDependencyException: Plugin 
is not installable on Geronimo 2.1.1 Missing dependency: 
org.apache.geronimo.samples/servlet-examples-tomcat/2.1-SNAPSHOT/car"


Guess we need to remove that plugin once we have the Samples updated and 
released for 2.1.



-Donald



Joe Bohn wrote:

Lin Sun wrote:

Joe, I ran some test against the 2.1.1 plugin repo 2 weeks ago and I
could not install the sample plugins I tried - forgot the error/prob
(think I tried the servlet and jsp samples).

Lin


There is 1 problem here and a few misunderstandings based upon that 
problem:


Problem:
- The default for the plugin repo for Geronimo 2.1.1 is actually the 
plugin repo for 2.1.  In order to see the Geronimo 2.1.1 plugin repo you 
must manually add the repository.  See this thread for a discussion of 
this issue: 
http://www.nabble.com/plugin-repository-for-2.1.1-td16990905s134.html



The not yet released samples (2.1-SNAPSHOT) are tied to Geronimo 2.1 and 
not Geronimo 2.1.1.  This is why I have been interested in getting 
samples released for 2.1 and 2.1.1.  The 2.1-SNAPSHOT samples appear in 
the 2.1 repository but not the 2.1.1 repository.  So, if you reference 
the 2.1.1 repository you will not see the samples listed at all and not 
encounter a problem on the install. Of course, that is tricky to do 
since we show you the wrong repository by default in 2.1.1.


So, I think what happened was that you accessed the 2.1 repository from 
a 2.1.1 server and attempted to install one of the sample plugins from 
there.


There is one more problem that you or others may hit regarding attempts 
to install samples in 2.1.1 at this time.  The servlet, jsp, and ldap 
samples are referenced directly from default/welcome servlet (/) and can 
optionally be installed from there.  An attempt to install them from 
this location will also fail given that it is referencing the same 
incorrect, default plugin repo for 2.1.


To summarize ... the 2.1.1 repo is not broken AFAIK (if it is broken 
then we can easily fix it).  What is broken is that 2.1.1 references the 
wrong plugin repo by default.  That problem will be fixed when we 
release 2.1.2.


Joe



On Fri, Jun 27, 2008 at 9:09 AM, Joe Bohn <[EMAIL PROTECTED]> wrote:

Donald Woods wrote:
Yeah, but until plugins built on earlier releases (like 2.1) work on 
later
maintenance updates (like 2.1.1 and 2.1.2) and we fix the currently 
broken

2.1.1 plugin repo, I don't think we really want to over-hype this
feature
By "the currently broken 2.1.1 plugin repo" do you just mean the fact 
that
in G 2.1.1 the console defaults to the 2.1 plugin repo rather than 
the 2.1.1
plugin repo?  The 2.1.1 plugin repo itself is not broken AFAIK and 
should

work correctly if you access it.

Joe




-Donald


Jarek Gawor wrote:

Yeah, that's a good point. But there are some things we could do
without the collapsible tree, for example, ensure that the debug views
always show up on the bottom, or combine "Information" and "Java
System Info" into one portlet.

Anyway, I proposed this change becuase I feel like we should make
plugins and plugins infrastructure much more visible. Not only in the
console but everywhere else such as the website, documentation, etc.

Jarek

On Thu, Jun 26, 2008 at 4:54 PM, Donald Woods <[EMAIL PROTECTED]> 
wrote:

I'd rather keep Plugins under applications.

As Joe pointed out, the navigational tree is already taking up too 
much
vertical space now for lower resolution displays.  Maybe if we 
ever have

the
collapsible tree again, then we could rearrange/regroup the 
portlets...



-Donald



Jarek Gawor wrote:

Hey,

Right now, the plugins portlet is not all that visible in the admin
console (it's under Applications / Plugins). I think it would be 
great

to make it more visible by creating a new "Plugins" section with
"Install", "Export", and "Assemble Server" subsections. I already
created three separate portlets for these plugin operations so
rearranging things visually should be easy.

Thoughts?

Jarek










smime.p7s
Description: S/MIME Cryptographic Signature

Re: Reducing the dojo footprint in Geronimo

Sounds like the right solution, given that would allow our console to 
upgrade at a slower pace and would allow users to choose their own level...


Other option, is to drop the /dojo webapp in 2.2, only ship what we need 
in the console and let users package the Dojo level and features they 
need within their own apps (which is more portable across different 
servers anyway)



-Donald


Kevan Miller wrote:


On Jun 27, 2008, at 11:00 AM, Shrey Banga wrote:



As for the including the rest of DojoX, since it a significant part of 
the reducing effort.  Would it make sense to build a custom js for 
monitoring, remove the rest of DojoX and if the development starts 
shifting to a real need for DojoX to make a decision to bring it back 
in the future?


I think that makes perfect sense- not only will this do the part in 
reducing the dojo footprint, it'll also be useful as an example to how 
dojo should be used optimally in deployment. Another desirable 
side-effect would be reduced load times in the monitoring application, 
although currently that is not an issue.


I'm starting to think that our server should deliver dojo support that 
is targeted to the requirements of the admin console.


For general dojo support, we could provide an installable dojo plugin 
that's equivalent to the /dojo support we currently provide...


--kevan



smime.p7s
Description: S/MIME Cryptographic Signature

Re: GEP trunk is still using version=2.1.1

2008-06-27 Thread Tim McConnell


Opps, my fault, will take care of. Thanks much

Donald Woods wrote:
BTW - the GEP trunk is still using version=2.1.1 for the built 
artifacts, even though 2.1.1 has been tagged and released..



-Donald


--
Thanks,
Tim McConnell

[jira] Closed: (GERONIMO-3983) Update JMS Resource portlet to show the Destination statistics


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donald Woods closed GERONIMO-3983.
--

Resolution: Fixed

Applied as r672342 in trunk (2.2-SNAPSHOT).
Anish, thanks for the patch.

> Update JMS Resource portlet to show the Destination statistics
> --
>
> Key: GERONIMO-3983
> URL: https://issues.apache.org/jira/browse/GERONIMO-3983
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>Reporter: Anish Pathadan
>Assignee: Donald Woods
> Fix For: 2.2
>
> Attachments: JMS Resource Portlet_Statistics.patch, screenshot-1.jpg
>
>
> Update the JMS Resource portlet to show the destination statistics such as 
> Consumer Count,Queue Size,Enqueue Count and Dequeue Count for each 
> Queues/Topics.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GERONIMO-4168) JSR319 - Availability Management for Java

2008-06-27 Thread Alan Cabrera (JIRA)

JSR319 - Availability Management for Java
-

 Key: GERONIMO-4168
 URL: https://issues.apache.org/jira/browse/GERONIMO-4168
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public (Regular issues)
  Components: specs
Reporter: Alan Cabrera
Assignee: Alan Cabrera


Will place in v0.4 version of the spec.  Will update as the spec evolves.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

JSR319 - Availability Management for Java

2008-06-27 Thread Alan Cabrera

This looks pretty interesting to me.  I'm going to start goofing  
around with it even though the spec version is 0.4 and I never seem to  
have a lot of time on my hands.


Anyone else interested as well?


Regards,
Alan

[jira] Closed: (GERONIMO-3974) Shutdown exceptions on IBM JVM


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donald Woods closed GERONIMO-3974.
--

Resolution: Fixed

r671360 in branches/2.1 (2.1.2-SNAPSHOT)
r672335 in trunk (2.2-SNAPSHOT)



> Shutdown exceptions on IBM JVM
> --
>
> Key: GERONIMO-3974
> URL: https://issues.apache.org/jira/browse/GERONIMO-3974
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: connector
>Affects Versions: 2.1.1, 2.1.2, 2.2
> Environment: Windows
>Reporter: YunFeng Ma
>Assignee: Donald Woods
>Priority: Minor
> Fix For: 2.1.2, 2.2
>
> Attachments: GERONIMO-3974-2.1.2.patch, GERONIMO-3974.patch
>
>
> Shutdown a clean Geronimo server, get the following exceptions:
> {noformat}
> Geronimo Application Server started
> 16:43:00,843 WARN  [GeronimoConnectionEventListener] connectionErrorOccurred 
> called with null
> java.sql.SQLException: No current connection.
> at 
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown 
> Source)
> at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown 
> Source)
> at org.apache.derby.impl.jdbc.Util.noCurrentConnection(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.checkIfClosed(Unknown 
> Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.getAutoCommit(Unknown 
> Source)
> at 
> org.apache.derby.iapi.jdbc.BrokeredConnection.getAutoCommit(Unknown Source)
> at 
> org.tranql.connector.jdbc.ConnectionHandle.rollback(ConnectionHandle.java:129)
> at 
> org.apache.activemq.store.jdbc.DefaultDatabaseLocker.stop(DefaultDatabaseLocker.java:78)
> at 
> org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.stop(JDBCPersistenceAdapter.java:202)
> at 
> org.apache.activemq.store.journal.JournalPersistenceAdapter.stop(JournalPersistenceAdapter.java:254)
> at 
> org.apache.activemq.util.ServiceStopper.stop(ServiceStopper.java:42)
> at 
> org.apache.activemq.broker.BrokerService.stop(BrokerService.java:443)
> at 
> org.apache.geronimo.activemq.BrokerServiceGBeanImpl.doStop(BrokerServiceGBeanImpl.java:119)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.destroyInstance(GBeanInstance.java:1161)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop(GBeanInstanceState.java:339)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:188)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:563)
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:563)
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:563)
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:563)
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:563)
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:563)
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423)
> at 
> org.apache.geronimo.kernel.config.KernelConfigurationManager$ShutdownHook.run(KernelConfigurationManager.java:316)
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.notifyShutdownHooks(BasicKernel.java:668)
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.shutdown(BasicKernel.java:645)
> at 
> org.apache.geronimo.kernel.KernelGBean.shutdown(KernelGBean.java:382)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce

[jira] Closed: (GERONIMO-4167) MimeMesage.reply() is not setting the In-Reply-To and Responses headers in the reply message

2008-06-27 Thread Rick McGuire (JIRA)


 [ 
https://issues.apache.org/jira/browse/GERONIMO-4167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rick McGuire closed GERONIMO-4167.
--

Resolution: Fixed

Committed revision 672333.

> MimeMesage.reply() is not setting the In-Reply-To and Responses headers in 
> the reply message
> 
>
> Key: GERONIMO-4167
> URL: https://issues.apache.org/jira/browse/GERONIMO-4167
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: mail
>Reporter: Rick McGuire
>Assignee: Rick McGuire
> Fix For: 2.2
>
>
> The Sun 1.4.1 version of javamail sets the In-Reply-To and Responses headers 
> when replying to a message.  This is missing from the Geronimo version. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GERONIMO-4167) MimeMesage.reply() is not setting the In-Reply-To and Responses headers in the reply message

2008-06-27 Thread Rick McGuire (JIRA)

MimeMesage.reply() is not setting the In-Reply-To and Responses headers in the 
reply message


 Key: GERONIMO-4167
 URL: https://issues.apache.org/jira/browse/GERONIMO-4167
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: mail
Reporter: Rick McGuire
Assignee: Rick McGuire
 Fix For: 2.2


The Sun 1.4.1 version of javamail sets the In-Reply-To and Responses headers 
when replying to a message.  This is missing from the Geronimo version. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMODEVTOOLS-367) unable to include modules and ext-modules

2008-06-27 Thread B.J. Reed (JIRA)


 [ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

B.J. Reed updated GERONIMODEVTOOLS-367:
---

Attachment: GERONIMODEVTOOLS-367.patch

Patch updates the application deploymnet plan editor to allow the manipulation 
of the module list and ext-module lists.

> unable to include modules and ext-modules
> -
>
> Key: GERONIMODEVTOOLS-367
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-367
> Project: Geronimo-Devtools
>  Issue Type: Sub-task
>  Components: eclipse-plugin
>Affects Versions: 2.1.x
>Reporter: B.J. Reed
>Assignee: B.J. Reed
>Priority: Minor
> Fix For: 2.1.2
>
> Attachments: GERONIMODEVTOOLS-367.patch
>
>
> The application deployment plan editor does not have a way to maintain the 
> module and ext-module lists.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMODEVTOOLS-392) unable to set hidden-classes and non-overridable-classes for environment

2008-06-27 Thread B.J. Reed (JIRA)


 [ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

B.J. Reed updated GERONIMODEVTOOLS-392:
---

Attachment: GERONIMODEVTOOLS-392.patch

Patch to include the non overridable class list and hidden class list on the 
deployment page.  Also has the support for saving the data.

> unable to set hidden-classes and non-overridable-classes for environment
> 
>
> Key: GERONIMODEVTOOLS-392
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-392
> Project: Geronimo-Devtools
>  Issue Type: Sub-task
>  Components: eclipse-plugin
>Affects Versions: 2.1.x
>Reporter: B.J. Reed
>Assignee: B.J. Reed
>Priority: Minor
> Fix For: 2.1.2
>
> Attachments: GERONIMODEVTOOLS-392.patch
>
>
> all deployment plan editors.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Reducing the dojo footprint in Geronimo

2008-06-27 Thread Kevan Miller



On Jun 27, 2008, at 11:00 AM, Shrey Banga wrote:



As for the including the rest of DojoX, since it a significant part  
of the reducing effort.  Would it make sense to build a custom js  
for monitoring, remove the rest of DojoX and if the development  
starts shifting to a real need for DojoX to make a decision to bring  
it back in the future?


I think that makes perfect sense- not only will this do the part in  
reducing the dojo footprint, it'll also be useful as an example to  
how dojo should be used optimally in deployment. Another desirable  
side-effect would be reduced load times in the monitoring  
application, although currently that is not an issue.


I'm starting to think that our server should deliver dojo support that  
is targeted to the requirements of the admin console.


For general dojo support, we could provide an installable dojo plugin  
that's equivalent to the /dojo support we currently provide...


--kevan

Re: making plugins (plugins portlet) more visible in the console

2008-06-27 Thread Kevan Miller



On Jun 25, 2008, at 3:04 PM, Jarek Gawor wrote:


Hey,

Right now, the plugins portlet is not all that visible in the admin
console (it's under Applications / Plugins). I think it would be great
to make it more visible by creating a new "Plugins" section with
"Install", "Export", and "Assemble Server" subsections. I already
created three separate portlets for these plugin operations so
rearranging things visually should be easy.


Adding to the fray... :-P

I'm not so sure that "Assemble Server" logically belongs with the  
"Plugin Install" and "Plugin Export" functions. Personally, I think  
it's a bit hard to find under "Plugins". I'm fine having "Plugin  
Install" and "Plugin Export" under Applications.


Are we discussing this for branches/2.1 or trunk? I don't think we  
should be making too many 2.1 changes. I think we could look at a good  
re-org on trunk (if there's interest).


--kevan

Re: Reducing the dojo footprint in Geronimo

2008-06-27 Thread Shrey Banga

> As for the including the rest of DojoX, since it a significant part of the
> reducing effort.  Would it make sense to build a custom js for monitoring,
> remove the rest of DojoX and if the development starts shifting to a real
> need for DojoX to make a decision to bring it back in the future?


I think that makes perfect sense- not only will this do the part in reducing
the dojo footprint, it'll also be useful as an example to how dojo should be
used optimally in deployment. Another desirable side-effect would be reduced
load times in the monitoring application, although currently that is not an
issue.

On Fri, Jun 27, 2008 at 8:07 PM, Joseph Leong <[EMAIL PROTECTED]>
wrote:

> I agree with you Jason and I feel 'experimental' can be casted in different
> light.  Looking at it's function exclusively, it seems to be fitting our
> needs and is stable from what i can see.  Having said that, i agree with
> your approach Shrey - The part where you mentioned the ability to create a
> custom js for the specific functionality of the monitoring console that
> required particular dojox dependencies.  So that would give us the slimmest
> version of what we want from DojoX and allow us to remove the rest.
>
> As for the including the rest of DojoX, since it a significant part of the
> reducing effort.  Would it make sense to build a custom js for monitoring,
> remove the rest of DojoX and if the development starts shifting to a real
> need for DojoX to make a decision to bring it back in the future? As pointed
> out, a lot of the functionality can be and was intended to be completed with
> dijit and dojo. Thoughts?
>
> -Joseph Leong
>
>
>
>
> On Fri, Jun 27, 2008 at 8:58 AM, Shrey Banga <[EMAIL PROTECTED]>
> wrote:
>
>> Donald,
>>
>> Are you suggesting we build all of the dojo, dijit and dojox scripts into
>> one single js and use that? I think that will be highly inexpedient.
>> For one, running the builder for all possible scripts in dojo is both
>> extremely tedious as the builder requires that we provide the basic modules
>> that our webapp needs, similar to dojo.requires in the webpages. In this
>> case, we'll have to require all the modules to be sure that none are left.
>> Even if we manage to do that, what we'll get is a massive js that will kill
>> most, if not all, webapps. What I'm suggesting is to build the specific
>> modules required by the Monitor application into one js and include that
>> within the application instead of using the dojo files in the repository.
>> Then we can get rid of dojox and advise users to do the same.
>>
>>
>> On Fri, Jun 27, 2008 at 6:10 PM, Donald Woods <[EMAIL PROTECTED]> wrote:
>>
>>> Then why not keep the dojox and just rebuild everything (minnus the demo
>>> and test files) into a single .js for the Dojo Plugin?
>>>
>>> I really don't want 2 copies of this in the server, which would be worse
>>> than 1 larger copy
>>>
>>>
>>> -Donald
>>>
>>>
>>> Shrey Banga wrote:
>>>
 Dojo does have a builder which can parse the dojo tree to create a
 single .js that is compressed and can be included with the webapp. Although
 this is intended for the purpose of speeding up webpages and avoiding lock
 up of resources while all the js is loaded, it can be used similarly for 
 the
 purpose of the monitor console so that dojox can be removed from the
 repository and the .js that has been built can be included with the 
 monitor.
 I think this would be a better approach than manually fishing out the
 required js. This should be the approach any geronimo user intending to use
 dojox features should use as they are bound to change in further releases.
 As Lin Sun pointed out, we shouldn't really be using the experimental
 features anyway. As and when these features are accommodated in the
 dojo/dijit components we can include them too.

 On Fri, Jun 27, 2008 at 2:29 AM, Lin Sun <[EMAIL PROTECTED] >>> [EMAIL PROTECTED]>> wrote:

Would it be possible that we release the monitor console piece as an
external plugin where users can install it on demand?  That way,
whoever wants to see the monitor console piece can install it along
with the dojox dependency and we don't need to figure out/bundle
 which
pieces of dojox we need.Also, I am a bit surprised that we are
using dojox as that is supposed to be incubator phase for dojo.

Lin




 --
 Shrey Banga
 Bachelor of Technology, III year
 Department of Electrical Engineering
 Indian Institute of Technology Roorkee

>>>
>>
>>
>> --
>> Shrey Banga
>> Bachelor of Technology, III year
>> Department of Electrical Engineering
>> Indian Institute of Technology Roorkee
>>
>
>


-- 
Shrey Banga
Bachelor of Technology, III year
Department of Electrical Engineering
Indian Institute of Technology Roorkee

Re: [ANNOUNCE] Lin Sun is the newest member of the Geronimo PMC

2008-06-27 Thread Phani Madgula

congrats Lin

On Fri, Jun 27, 2008 at 4:24 PM, Ashish Jain <[EMAIL PROTECTED]> wrote:

> Congratulations Lin Sun.
>
>
> On Fri, Jun 27, 2008 at 3:11 PM, Manu George <[EMAIL PROTECTED]>
> wrote:
>
>> Congrats Lin
>>
>> On Fri, Jun 27, 2008 at 2:14 PM, Lei Wang <[EMAIL PROTECTED]> wrote:
>> > Lin, congratulations!
>> >
>> > Rex
>> >
>> > 2008/6/27 Jarek Gawor <[EMAIL PROTECTED]>:
>> >>
>> >> All,
>> >>
>> >> Please join us in congratulating Lin Sun as the newest member of the
>> >> Geronimo PMC. She has been involved with the Geronimo community for a
>> >> long time and made great contributions as a committer and otherwise.
>> >> She will be a great addition to the PMC.
>> >>
>> >> Congratulations Lin!
>> >>
>> >> The Apache Geronimo PMC
>> >
>> >
>>
>
>

[jira] Updated: (GERONIMO-3503) DBPool wizzard creates plans only for local-transactions

2008-06-27 Thread Lin Sun (JIRA)


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lin Sun updated GERONIMO-3503:
--

Fix Version/s: (was: 2.0.x)
   2.1.2

> DBPool wizzard creates plans only for local-transactions
> 
>
> Key: GERONIMO-3503
> URL: https://issues.apache.org/jira/browse/GERONIMO-3503
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Reporter: Tomasz Mazan
>Assignee: Lin Sun
> Fix For: 2.1.2, 2.1.x, 2.2
>
> Attachments: G3503-r671547.patch
>
>
> I use DatabasePool Wizzard to deploy Pools for PostgresQL. 
> In both cases - I choosed PostgreAQL XA or PostgreSQL Local - wizzard 
> generated plan with model 
> 
> 
> 
> 10
> 0
> 
> 
> 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Reducing the dojo footprint in Geronimo

2008-06-27 Thread Joseph Leong

I agree with you Jason and I feel 'experimental' can be casted in different
light.  Looking at it's function exclusively, it seems to be fitting our
needs and is stable from what i can see.  Having said that, i agree with
your approach Shrey - The part where you mentioned the ability to create a
custom js for the specific functionality of the monitoring console that
required particular dojox dependencies.  So that would give us the slimmest
version of what we want from DojoX and allow us to remove the rest.

As for the including the rest of DojoX, since it a significant part of the
reducing effort.  Would it make sense to build a custom js for monitoring,
remove the rest of DojoX and if the development starts shifting to a real
need for DojoX to make a decision to bring it back in the future? As pointed
out, a lot of the functionality can be and was intended to be completed with
dijit and dojo. Thoughts?

-Joseph Leong



On Fri, Jun 27, 2008 at 8:58 AM, Shrey Banga <[EMAIL PROTECTED]> wrote:

> Donald,
>
> Are you suggesting we build all of the dojo, dijit and dojox scripts into
> one single js and use that? I think that will be highly inexpedient.
> For one, running the builder for all possible scripts in dojo is both
> extremely tedious as the builder requires that we provide the basic modules
> that our webapp needs, similar to dojo.requires in the webpages. In this
> case, we'll have to require all the modules to be sure that none are left.
> Even if we manage to do that, what we'll get is a massive js that will kill
> most, if not all, webapps. What I'm suggesting is to build the specific
> modules required by the Monitor application into one js and include that
> within the application instead of using the dojo files in the repository.
> Then we can get rid of dojox and advise users to do the same.
>
>
> On Fri, Jun 27, 2008 at 6:10 PM, Donald Woods <[EMAIL PROTECTED]> wrote:
>
>> Then why not keep the dojox and just rebuild everything (minnus the demo
>> and test files) into a single .js for the Dojo Plugin?
>>
>> I really don't want 2 copies of this in the server, which would be worse
>> than 1 larger copy
>>
>>
>> -Donald
>>
>>
>> Shrey Banga wrote:
>>
>>> Dojo does have a builder which can parse the dojo tree to create a single
>>> .js that is compressed and can be included with the webapp. Although this is
>>> intended for the purpose of speeding up webpages and avoiding lock up of
>>> resources while all the js is loaded, it can be used similarly for the
>>> purpose of the monitor console so that dojox can be removed from the
>>> repository and the .js that has been built can be included with the monitor.
>>> I think this would be a better approach than manually fishing out the
>>> required js. This should be the approach any geronimo user intending to use
>>> dojox features should use as they are bound to change in further releases.
>>> As Lin Sun pointed out, we shouldn't really be using the experimental
>>> features anyway. As and when these features are accommodated in the
>>> dojo/dijit components we can include them too.
>>>
>>> On Fri, Jun 27, 2008 at 2:29 AM, Lin Sun <[EMAIL PROTECTED] >> [EMAIL PROTECTED]>> wrote:
>>>
>>>Would it be possible that we release the monitor console piece as an
>>>external plugin where users can install it on demand?  That way,
>>>whoever wants to see the monitor console piece can install it along
>>>with the dojox dependency and we don't need to figure out/bundle which
>>>pieces of dojox we need.Also, I am a bit surprised that we are
>>>using dojox as that is supposed to be incubator phase for dojo.
>>>
>>>Lin
>>>
>>>
>>>
>>>
>>> --
>>> Shrey Banga
>>> Bachelor of Technology, III year
>>> Department of Electrical Engineering
>>> Indian Institute of Technology Roorkee
>>>
>>
>
>
> --
> Shrey Banga
> Bachelor of Technology, III year
> Department of Electrical Engineering
> Indian Institute of Technology Roorkee
>

[jira] Resolved: (GERONIMO-3503) DBPool wizzard creates plans only for local-transactions

2008-06-27 Thread Lin Sun (JIRA)


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lin Sun resolved GERONIMO-3503.
---

Resolution: Fixed

Tested and Integrated the patch from Manu - see subversion commits section.



> DBPool wizzard creates plans only for local-transactions
> 
>
> Key: GERONIMO-3503
> URL: https://issues.apache.org/jira/browse/GERONIMO-3503
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Reporter: Tomasz Mazan
>Assignee: Lin Sun
> Fix For: 2.0.x, 2.1.x, 2.2
>
> Attachments: G3503-r671547.patch
>
>
> I use DatabasePool Wizzard to deploy Pools for PostgresQL. 
> In both cases - I choosed PostgreAQL XA or PostgreSQL Local - wizzard 
> generated plan with model 
> 
> 
> 
> 10
> 0
> 
> 
> 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: making plugins (plugins portlet) more visible in the console


Lin Sun wrote:

Joe, I ran some test against the 2.1.1 plugin repo 2 weeks ago and I
could not install the sample plugins I tried - forgot the error/prob
(think I tried the servlet and jsp samples).

Lin


There is 1 problem here and a few misunderstandings based upon that problem:

Problem:
- The default for the plugin repo for Geronimo 2.1.1 is actually the 
plugin repo for 2.1.  In order to see the Geronimo 2.1.1 plugin repo you 
must manually add the repository.  See this thread for a discussion of 
this issue: 
http://www.nabble.com/plugin-repository-for-2.1.1-td16990905s134.html



The not yet released samples (2.1-SNAPSHOT) are tied to Geronimo 2.1 and 
not Geronimo 2.1.1.  This is why I have been interested in getting 
samples released for 2.1 and 2.1.1.  The 2.1-SNAPSHOT samples appear in 
the 2.1 repository but not the 2.1.1 repository.  So, if you reference 
the 2.1.1 repository you will not see the samples listed at all and not 
encounter a problem on the install. Of course, that is tricky to do 
since we show you the wrong repository by default in 2.1.1.


So, I think what happened was that you accessed the 2.1 repository from 
a 2.1.1 server and attempted to install one of the sample plugins from 
there.


There is one more problem that you or others may hit regarding attempts 
to install samples in 2.1.1 at this time.  The servlet, jsp, and ldap 
samples are referenced directly from default/welcome servlet (/) and can 
optionally be installed from there.  An attempt to install them from 
this location will also fail given that it is referencing the same 
incorrect, default plugin repo for 2.1.


To summarize ... the 2.1.1 repo is not broken AFAIK (if it is broken 
then we can easily fix it).  What is broken is that 2.1.1 references the 
wrong plugin repo by default.  That problem will be fixed when we 
release 2.1.2.


Joe



On Fri, Jun 27, 2008 at 9:09 AM, Joe Bohn <[EMAIL PROTECTED]> wrote:

Donald Woods wrote:

Yeah, but until plugins built on earlier releases (like 2.1) work on later
maintenance updates (like 2.1.1 and 2.1.2) and we fix the currently broken
2.1.1 plugin repo, I don't think we really want to over-hype this
feature

By "the currently broken 2.1.1 plugin repo" do you just mean the fact that
in G 2.1.1 the console defaults to the 2.1 plugin repo rather than the 2.1.1
plugin repo?  The 2.1.1 plugin repo itself is not broken AFAIK and should
work correctly if you access it.

Joe




-Donald


Jarek Gawor wrote:

Yeah, that's a good point. But there are some things we could do
without the collapsible tree, for example, ensure that the debug views
always show up on the bottom, or combine "Information" and "Java
System Info" into one portlet.

Anyway, I proposed this change becuase I feel like we should make
plugins and plugins infrastructure much more visible. Not only in the
console but everywhere else such as the website, documentation, etc.

Jarek

On Thu, Jun 26, 2008 at 4:54 PM, Donald Woods <[EMAIL PROTECTED]> wrote:

I'd rather keep Plugins under applications.

As Joe pointed out, the navigational tree is already taking up too much
vertical space now for lower resolution displays.  Maybe if we ever have
the
collapsible tree again, then we could rearrange/regroup the portlets...


-Donald



Jarek Gawor wrote:

Hey,

Right now, the plugins portlet is not all that visible in the admin
console (it's under Applications / Plugins). I think it would be great
to make it more visible by creating a new "Plugins" section with
"Install", "Export", and "Assemble Server" subsections. I already
created three separate portlets for these plugin operations so
rearranging things visually should be easy.

Thoughts?

Jarek

Re: making plugins (plugins portlet) more visible in the console

2008-06-27 Thread Lin Sun

Joe, I ran some test against the 2.1.1 plugin repo 2 weeks ago and I
could not install the sample plugins I tried - forgot the error/prob
(think I tried the servlet and jsp samples).

Lin

On Fri, Jun 27, 2008 at 9:09 AM, Joe Bohn <[EMAIL PROTECTED]> wrote:
> Donald Woods wrote:
>>
>> Yeah, but until plugins built on earlier releases (like 2.1) work on later
>> maintenance updates (like 2.1.1 and 2.1.2) and we fix the currently broken
>> 2.1.1 plugin repo, I don't think we really want to over-hype this
>> feature
>
> By "the currently broken 2.1.1 plugin repo" do you just mean the fact that
> in G 2.1.1 the console defaults to the 2.1 plugin repo rather than the 2.1.1
> plugin repo?  The 2.1.1 plugin repo itself is not broken AFAIK and should
> work correctly if you access it.
>
> Joe
>
>
>>
>>
>> -Donald
>>
>>
>> Jarek Gawor wrote:
>>>
>>> Yeah, that's a good point. But there are some things we could do
>>> without the collapsible tree, for example, ensure that the debug views
>>> always show up on the bottom, or combine "Information" and "Java
>>> System Info" into one portlet.
>>>
>>> Anyway, I proposed this change becuase I feel like we should make
>>> plugins and plugins infrastructure much more visible. Not only in the
>>> console but everywhere else such as the website, documentation, etc.
>>>
>>> Jarek
>>>
>>> On Thu, Jun 26, 2008 at 4:54 PM, Donald Woods <[EMAIL PROTECTED]> wrote:

 I'd rather keep Plugins under applications.

 As Joe pointed out, the navigational tree is already taking up too much
 vertical space now for lower resolution displays.  Maybe if we ever have
 the
 collapsible tree again, then we could rearrange/regroup the portlets...


 -Donald



 Jarek Gawor wrote:
>
> Hey,
>
> Right now, the plugins portlet is not all that visible in the admin
> console (it's under Applications / Plugins). I think it would be great
> to make it more visible by creating a new "Plugins" section with
> "Install", "Export", and "Assemble Server" subsections. I already
> created three separate portlets for these plugin operations so
> rearranging things visually should be easy.
>
> Thoughts?
>
> Jarek
>
>>>
>
>

Re: making plugins (plugins portlet) more visible in the console


Donald Woods wrote:
Yeah, but until plugins built on earlier releases (like 2.1) work on 
later maintenance updates (like 2.1.1 and 2.1.2) and we fix the 
currently broken 2.1.1 plugin repo, I don't think we really want to 
over-hype this feature


By "the currently broken 2.1.1 plugin repo" do you just mean the fact 
that in G 2.1.1 the console defaults to the 2.1 plugin repo rather than 
the 2.1.1 plugin repo?  The 2.1.1 plugin repo itself is not broken AFAIK 
and should work correctly if you access it.


Joe





-Donald


Jarek Gawor wrote:

Yeah, that's a good point. But there are some things we could do
without the collapsible tree, for example, ensure that the debug views
always show up on the bottom, or combine "Information" and "Java
System Info" into one portlet.

Anyway, I proposed this change becuase I feel like we should make
plugins and plugins infrastructure much more visible. Not only in the
console but everywhere else such as the website, documentation, etc.

Jarek

On Thu, Jun 26, 2008 at 4:54 PM, Donald Woods <[EMAIL PROTECTED]> wrote:

I'd rather keep Plugins under applications.

As Joe pointed out, the navigational tree is already taking up too much
vertical space now for lower resolution displays.  Maybe if we ever 
have the

collapsible tree again, then we could rearrange/regroup the portlets...


-Donald



Jarek Gawor wrote:

Hey,

Right now, the plugins portlet is not all that visible in the admin
console (it's under Applications / Plugins). I think it would be great
to make it more visible by creating a new "Plugins" section with
"Install", "Export", and "Assemble Server" subsections. I already
created three separate portlets for these plugin operations so
rearranging things visually should be easy.

Thoughts?

Jarek

Re: Reducing the dojo footprint in Geronimo

2008-06-27 Thread Shrey Banga

Donald,

Are you suggesting we build all of the dojo, dijit and dojox scripts into
one single js and use that? I think that will be highly inexpedient.
For one, running the builder for all possible scripts in dojo is both
extremely tedious as the builder requires that we provide the basic modules
that our webapp needs, similar to dojo.requires in the webpages. In this
case, we'll have to require all the modules to be sure that none are left.
Even if we manage to do that, what we'll get is a massive js that will kill
most, if not all, webapps. What I'm suggesting is to build the specific
modules required by the Monitor application into one js and include that
within the application instead of using the dojo files in the repository.
Then we can get rid of dojox and advise users to do the same.

On Fri, Jun 27, 2008 at 6:10 PM, Donald Woods <[EMAIL PROTECTED]> wrote:

> Then why not keep the dojox and just rebuild everything (minnus the demo
> and test files) into a single .js for the Dojo Plugin?
>
> I really don't want 2 copies of this in the server, which would be worse
> than 1 larger copy
>
>
> -Donald
>
>
> Shrey Banga wrote:
>
>> Dojo does have a builder which can parse the dojo tree to create a single
>> .js that is compressed and can be included with the webapp. Although this is
>> intended for the purpose of speeding up webpages and avoiding lock up of
>> resources while all the js is loaded, it can be used similarly for the
>> purpose of the monitor console so that dojox can be removed from the
>> repository and the .js that has been built can be included with the monitor.
>> I think this would be a better approach than manually fishing out the
>> required js. This should be the approach any geronimo user intending to use
>> dojox features should use as they are bound to change in further releases.
>> As Lin Sun pointed out, we shouldn't really be using the experimental
>> features anyway. As and when these features are accommodated in the
>> dojo/dijit components we can include them too.
>>
>> On Fri, Jun 27, 2008 at 2:29 AM, Lin Sun <[EMAIL PROTECTED] > [EMAIL PROTECTED]>> wrote:
>>
>>Would it be possible that we release the monitor console piece as an
>>external plugin where users can install it on demand?  That way,
>>whoever wants to see the monitor console piece can install it along
>>with the dojox dependency and we don't need to figure out/bundle which
>>pieces of dojox we need.Also, I am a bit surprised that we are
>>using dojox as that is supposed to be incubator phase for dojo.
>>
>>Lin
>>
>>
>>
>>
>> --
>> Shrey Banga
>> Bachelor of Technology, III year
>> Department of Electrical Engineering
>> Indian Institute of Technology Roorkee
>>
>

-- 
Shrey Banga
Bachelor of Technology, III year
Department of Electrical Engineering
Indian Institute of Technology Roorkee

Re: Reducing the dojo footprint in Geronimo

2008-06-27 Thread Jason Warner

I could be completely wrong on this, as I can't remember any specific
examples, but haven't we used incubator projects in geronimo before?  I
don't see any issue with using dojox if it's the best fit for our needs and
the code is stable, which I believe it has proven itself to be.

On Thu, Jun 26, 2008 at 4:59 PM, Lin Sun <[EMAIL PROTECTED]> wrote:

> Would it be possible that we release the monitor console piece as an
> external plugin where users can install it on demand?  That way,
> whoever wants to see the monitor console piece can install it along
> with the dojox dependency and we don't need to figure out/bundle which
> pieces of dojox we need.Also, I am a bit surprised that we are
> using dojox as that is supposed to be incubator phase for dojo.
>
> Lin
>

-- 
~Jason Warner

[jira] Commented: (GERONIMO-4166) EAR missing dependency on j2ee-security breaks Server Console


[ 
https://issues.apache.org/jira/browse/GERONIMO-4166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608754#action_12608754
 ] 

Shrey Banga commented on GERONIMO-4166:
---

Adding the dependency to j2ee-security successfully deploys the application but 
with the buggy ear, it should have ideally reported the error on the server 
console and not have broken the Web App wars and Application EARs. 
I have attached timereport_buggy.ear and timereport.ear, the only difference 
being the dependency to j2ee-security.

> EAR missing dependency on j2ee-security breaks Server Console
> -
>
> Key: GERONIMO-4166
> URL: https://issues.apache.org/jira/browse/GERONIMO-4166
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.2
>Reporter: Shrey Banga
> Fix For: 2.2
>
> Attachments: dbPoolPlan.xml, securityRealmPlan.xml, timereport.ear, 
> timereport_buggy.ear, TimeReportDB.sql
>
>
> I created an ear with security configuration which seemed to get deployed 
> successfully but once deployed, the Web app wars and Application EARS 
> portlets failed with the exception:
> java.lang.NullPointerException
>   at 
> org.apache.geronimo.console.configmanager.ConfigManagerPortlet.doView(ConfigManagerPortlet.java:239)
>   at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247)
>   at javax.portlet.GenericPortlet.render(GenericPortlet.java:175)
>   at 
> org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:208)
>   at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:535)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:472)
>   at 
> org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167)
>   at 
> org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPortletInvokerService.java:101)
>   at 
> org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainerImpl.java:173)
>   at 
> org.apache.pluto.driver.tags.PortletTag.doStartTag(PortletTag.java:152)
>   at 
> jsp.WEB_002dINF.themes.portlet_002dskin_jsp._jspService(portlet_002dskin_jsp.java:87)
>   at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:535)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:472)
>   at 
> org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:968)
>   at 
> jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspx_meth_c_005fforEach_005f0(default_002dtheme_jsp.java:196)
>   at 
> jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspService(default_002dtheme_jsp.java:101)
>   at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302)
>   at 
> org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:151)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
>   at javax.servlet.http.HttpServlet.service(Htt

Re: Reducing the dojo footprint in Geronimo

Then why not keep the dojox and just rebuild everything (minnus the demo 
and test files) into a single .js for the Dojo Plugin?


I really don't want 2 copies of this in the server, which would be worse 
than 1 larger copy



-Donald


Shrey Banga wrote:
Dojo does have a builder which can parse the dojo tree to create a 
single .js that is compressed and can be included with the webapp. 
Although this is intended for the purpose of speeding up webpages and 
avoiding lock up of resources while all the js is loaded, it can be used 
similarly for the purpose of the monitor console so that dojox can be 
removed from the repository and the .js that has been built can be 
included with the monitor. I think this would be a better approach than 
manually fishing out the required js. This should be the approach any 
geronimo user intending to use dojox features should use as they are 
bound to change in further releases.
As Lin Sun pointed out, we shouldn't really be using the experimental 
features anyway. As and when these features are accommodated in the 
dojo/dijit components we can include them too.


On Fri, Jun 27, 2008 at 2:29 AM, Lin Sun <[EMAIL PROTECTED] 
> wrote:


Would it be possible that we release the monitor console piece as an
external plugin where users can install it on demand?  That way,
whoever wants to see the monitor console piece can install it along
with the dojox dependency and we don't need to figure out/bundle which
pieces of dojox we need.Also, I am a bit surprised that we are
using dojox as that is supposed to be incubator phase for dojo.

Lin




--
Shrey Banga
Bachelor of Technology, III year
Department of Electrical Engineering
Indian Institute of Technology Roorkee


smime.p7s
Description: S/MIME Cryptographic Signature

[jira] Commented: (GERONIMO-4163) Startup failed when use multi repository


[ 
https://issues.apache.org/jira/browse/GERONIMO-4163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608753#action_12608753
 ] 

Donald Woods commented on GERONIMO-4163:


Did you only verify against trunk (2.2-SNAPSHOT)?
Is it also fixed in 2.1.2-SNAPSHOT?

> Startup failed when use multi repository
> 
>
> Key: GERONIMO-4163
> URL: https://issues.apache.org/jira/browse/GERONIMO-4163
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: core
>Affects Versions: 2.1.1
> Environment: Geronimo v2.1.1, J2se6.0,winxp
>Reporter: wang
> Fix For: 2.2
>
> Attachments: myrepo.xml, plan.pml
>
>
> I use multi repository with version 2.1.1 as following the url: 
> 
> https://issues.apache.org/jira/browse/GERONIMO-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602153#action_12602153
> My use case just is one server instance with two repository. one dir is 
> repository, and another is repo2s. when I use command line to deploy plan to 
> repo2s, it works wonderful.but to restart the server is failed. the Exception 
> is bellow:
> org.apache.geronimo.kernel.config.NoSuchConfigException: test/first/1.0/car
>   at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfigurationData(SimpleConfigurationManager.java:476)
>   at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.sort(SimpleConfigurationManager.java:456)
>   at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.sort(SimpleConfigurationManager.java:448)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:597)
>   at 
> org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:832)
>   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.gbean.GBeanLifecycle$$EnhancerByCGLIB$$b9aaa102.sort()
>   at 
> org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:152)
>   at 
> org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:79)
>   at org.apache.geronimo.system.main.Daemon.main(Daemon.java:94)
>  
> There is problem with the method configurationManager.sort(). I did the same 
> test with version v1.1.1,fond that it works well.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-4166) EAR missing dependency on j2ee-security breaks Server Console


 [ 
https://issues.apache.org/jira/browse/GERONIMO-4166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shrey Banga updated GERONIMO-4166:
--

Attachment: timereport.ear
timereport_buggy.ear

> EAR missing dependency on j2ee-security breaks Server Console
> -
>
> Key: GERONIMO-4166
> URL: https://issues.apache.org/jira/browse/GERONIMO-4166
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.2
>Reporter: Shrey Banga
> Fix For: 2.2
>
> Attachments: dbPoolPlan.xml, securityRealmPlan.xml, timereport.ear, 
> timereport_buggy.ear, TimeReportDB.sql
>
>
> I created an ear with security configuration which seemed to get deployed 
> successfully but once deployed, the Web app wars and Application EARS 
> portlets failed with the exception:
> java.lang.NullPointerException
>   at 
> org.apache.geronimo.console.configmanager.ConfigManagerPortlet.doView(ConfigManagerPortlet.java:239)
>   at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247)
>   at javax.portlet.GenericPortlet.render(GenericPortlet.java:175)
>   at 
> org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:208)
>   at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:535)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:472)
>   at 
> org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167)
>   at 
> org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPortletInvokerService.java:101)
>   at 
> org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainerImpl.java:173)
>   at 
> org.apache.pluto.driver.tags.PortletTag.doStartTag(PortletTag.java:152)
>   at 
> jsp.WEB_002dINF.themes.portlet_002dskin_jsp._jspService(portlet_002dskin_jsp.java:87)
>   at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:535)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:472)
>   at 
> org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:968)
>   at 
> jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspx_meth_c_005fforEach_005f0(default_002dtheme_jsp.java:196)
>   at 
> jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspService(default_002dtheme_jsp.java:101)
>   at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302)
>   at 
> org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:151)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>   at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233

[jira] Updated: (GERONIMO-4166) EAR missing dependency on j2ee-security breaks Server Console


 [ 
https://issues.apache.org/jira/browse/GERONIMO-4166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shrey Banga updated GERONIMO-4166:
--

Attachment: securityRealmPlan.xml

> EAR missing dependency on j2ee-security breaks Server Console
> -
>
> Key: GERONIMO-4166
> URL: https://issues.apache.org/jira/browse/GERONIMO-4166
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.2
>Reporter: Shrey Banga
> Fix For: 2.2
>
> Attachments: dbPoolPlan.xml, securityRealmPlan.xml, TimeReportDB.sql
>
>
> I created an ear with security configuration which seemed to get deployed 
> successfully but once deployed, the Web app wars and Application EARS 
> portlets failed with the exception:
> java.lang.NullPointerException
>   at 
> org.apache.geronimo.console.configmanager.ConfigManagerPortlet.doView(ConfigManagerPortlet.java:239)
>   at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247)
>   at javax.portlet.GenericPortlet.render(GenericPortlet.java:175)
>   at 
> org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:208)
>   at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:535)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:472)
>   at 
> org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167)
>   at 
> org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPortletInvokerService.java:101)
>   at 
> org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainerImpl.java:173)
>   at 
> org.apache.pluto.driver.tags.PortletTag.doStartTag(PortletTag.java:152)
>   at 
> jsp.WEB_002dINF.themes.portlet_002dskin_jsp._jspService(portlet_002dskin_jsp.java:87)
>   at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:535)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:472)
>   at 
> org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:968)
>   at 
> jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspx_meth_c_005fforEach_005f0(default_002dtheme_jsp.java:196)
>   at 
> jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspService(default_002dtheme_jsp.java:101)
>   at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302)
>   at 
> org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:151)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>   at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
>   at 
> org.apache.catalina.core.StandardContextValve.invoke(St

[jira] Updated: (GERONIMO-4166) EAR missing dependency on j2ee-security breaks Server Console


 [ 
https://issues.apache.org/jira/browse/GERONIMO-4166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shrey Banga updated GERONIMO-4166:
--

Attachment: TimeReportDB.sql

> EAR missing dependency on j2ee-security breaks Server Console
> -
>
> Key: GERONIMO-4166
> URL: https://issues.apache.org/jira/browse/GERONIMO-4166
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.2
>Reporter: Shrey Banga
> Fix For: 2.2
>
> Attachments: dbPoolPlan.xml, securityRealmPlan.xml, TimeReportDB.sql
>
>
> I created an ear with security configuration which seemed to get deployed 
> successfully but once deployed, the Web app wars and Application EARS 
> portlets failed with the exception:
> java.lang.NullPointerException
>   at 
> org.apache.geronimo.console.configmanager.ConfigManagerPortlet.doView(ConfigManagerPortlet.java:239)
>   at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247)
>   at javax.portlet.GenericPortlet.render(GenericPortlet.java:175)
>   at 
> org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:208)
>   at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:535)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:472)
>   at 
> org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167)
>   at 
> org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPortletInvokerService.java:101)
>   at 
> org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainerImpl.java:173)
>   at 
> org.apache.pluto.driver.tags.PortletTag.doStartTag(PortletTag.java:152)
>   at 
> jsp.WEB_002dINF.themes.portlet_002dskin_jsp._jspService(portlet_002dskin_jsp.java:87)
>   at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:535)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:472)
>   at 
> org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:968)
>   at 
> jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspx_meth_c_005fforEach_005f0(default_002dtheme_jsp.java:196)
>   at 
> jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspService(default_002dtheme_jsp.java:101)
>   at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302)
>   at 
> org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:151)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>   at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
>   at 
> org.apache.catalina.core.StandardContextValve.invoke(Standar

[jira] Updated: (GERONIMO-4166) EAR missing dependency on j2ee-security breaks Server Console


 [ 
https://issues.apache.org/jira/browse/GERONIMO-4166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shrey Banga updated GERONIMO-4166:
--

Attachment: dbPoolPlan.xml

> EAR missing dependency on j2ee-security breaks Server Console
> -
>
> Key: GERONIMO-4166
> URL: https://issues.apache.org/jira/browse/GERONIMO-4166
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.2
>Reporter: Shrey Banga
> Fix For: 2.2
>
> Attachments: dbPoolPlan.xml, securityRealmPlan.xml, TimeReportDB.sql
>
>
> I created an ear with security configuration which seemed to get deployed 
> successfully but once deployed, the Web app wars and Application EARS 
> portlets failed with the exception:
> java.lang.NullPointerException
>   at 
> org.apache.geronimo.console.configmanager.ConfigManagerPortlet.doView(ConfigManagerPortlet.java:239)
>   at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247)
>   at javax.portlet.GenericPortlet.render(GenericPortlet.java:175)
>   at 
> org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:208)
>   at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:535)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:472)
>   at 
> org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167)
>   at 
> org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPortletInvokerService.java:101)
>   at 
> org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainerImpl.java:173)
>   at 
> org.apache.pluto.driver.tags.PortletTag.doStartTag(PortletTag.java:152)
>   at 
> jsp.WEB_002dINF.themes.portlet_002dskin_jsp._jspService(portlet_002dskin_jsp.java:87)
>   at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:535)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:472)
>   at 
> org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:968)
>   at 
> jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspx_meth_c_005fforEach_005f0(default_002dtheme_jsp.java:196)
>   at 
> jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspService(default_002dtheme_jsp.java:101)
>   at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302)
>   at 
> org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:151)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>   at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
>   at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardC

[jira] Created: (GERONIMO-4166) EAR missing dependency on j2ee-security breaks Server Console

EAR missing dependency on j2ee-security breaks Server Console
-

 Key: GERONIMO-4166
 URL: https://issues.apache.org/jira/browse/GERONIMO-4166
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: console
Affects Versions: 2.2
Reporter: Shrey Banga
 Fix For: 2.2
 Attachments: dbPoolPlan.xml, securityRealmPlan.xml, TimeReportDB.sql

I created an ear with security configuration which seemed to get deployed 
successfully but once deployed, the Web app wars and Application EARS portlets 
failed with the exception:
java.lang.NullPointerException
at 
org.apache.geronimo.console.configmanager.ConfigManagerPortlet.doView(ConfigManagerPortlet.java:239)
at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247)
at javax.portlet.GenericPortlet.render(GenericPortlet.java:175)
at 
org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:208)
at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630)
at 
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:535)
at 
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:472)
at 
org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167)
at 
org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPortletInvokerService.java:101)
at 
org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainerImpl.java:173)
at 
org.apache.pluto.driver.tags.PortletTag.doStartTag(PortletTag.java:152)
at 
jsp.WEB_002dINF.themes.portlet_002dskin_jsp._jspService(portlet_002dskin_jsp.java:87)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630)
at 
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:535)
at 
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:472)
at 
org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:968)
at 
jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspx_meth_c_005fforEach_005f0(default_002dtheme_jsp.java:196)
at 
jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspService(default_002dtheme_jsp.java:101)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630)
at 
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436)
at 
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374)
at 
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302)
at 
org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:151)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at 
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
at 
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStanda

Re: [ANNOUNCE] Lin Sun is the newest member of the Geronimo PMC

2008-06-27 Thread Ashish Jain

Congratulations Lin Sun.

On Fri, Jun 27, 2008 at 3:11 PM, Manu George <[EMAIL PROTECTED]>
wrote:

> Congrats Lin
>
> On Fri, Jun 27, 2008 at 2:14 PM, Lei Wang <[EMAIL PROTECTED]> wrote:
> > Lin, congratulations!
> >
> > Rex
> >
> > 2008/6/27 Jarek Gawor <[EMAIL PROTECTED]>:
> >>
> >> All,
> >>
> >> Please join us in congratulating Lin Sun as the newest member of the
> >> Geronimo PMC. She has been involved with the Geronimo community for a
> >> long time and made great contributions as a committer and otherwise.
> >> She will be a great addition to the PMC.
> >>
> >> Congratulations Lin!
> >>
> >> The Apache Geronimo PMC
> >
> >
>

[jira] Commented: (GERONIMO-4153) Messages are not being redelivered correctly


[ 
https://issues.apache.org/jira/browse/GERONIMO-4153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608716#action_12608716
 ] 

Mohammed Imran commented on GERONIMO-4153:
--

Here is my jms resource plan


http://geronimo.apache.org/xml/ns/j2ee/connector-1.2";>
http://geronimo.apache.org/xml/ns/deployment-1.2";>

my.jms
myJMSResources
1.0
rar



org.apache.geronimo.configs
activemq-broker
car






myJMSResources

vm://localhost
20

http://geronimo.apache.org/xml/ns/naming-1.2";>
DefaultWorkManager





javax.jms.ConnectionFactory

ConnectionFactory

javax.jms.QueueConnectionFactory

javax.jms.TopicConnectionFactory









5000
1













javax.jms.Queue

org.apache.activemq.command.ActiveMQQueue

ErrorQueue
ErrorQueue






Note I have changed the transaction type from xa, local and none, and have 
already changed the serverURl to be tcp://localhost:61616. However the messages 
still does not seem to be redelivered.

> Messages are not being redelivered correctly
> 
>
> Key: GERONIMO-4153
> URL: https://issues.apache.org/jira/browse/GERONIMO-4153
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: ActiveMQ
>Affects Versions: 2.1, 2.1.1
> Environment: Geronimo 2.1.1, Windows XP SP3. Java 1.6_0_6
>Reporter: Mohammed Imran
> Attachments: javaEEApplication.ear, src.zip
>
>
> I am experiencing problems with redelivery of messages in activemq/geronimo 
> it seems to not redeliver the message when a system exception occurs. I know 
> that ActiveMQ has a max redelivery count, however the messages seem to stop 
> being processed after 1-2 attempts. I am not getting anywhere near the max 
> redelivery count.
> I enclose a very simple example. This ear simple has 1 MDB which will 
> automatically throw an EJBException. (In the source code I have configured it 
> to use ActiveMQ default queues and connection factory this was only done so 
> you can quickly see what happens without setting up your own queue and 
> connection factory. I also enclose a runnable class which will send a message 
> to the queue.)
> The expected result should be MDB retires 5/10/xxx amount of times whatever 
> the max redelivery count is set to and then stops redelivering the message. 
> However as I have said earlier on I am not getting this, seems to only retry 
> once.
> package test;
> import javax.ejb.*;
> import javax.jms.MessageListener;
> import javax.jms.Message;
> @MessageDriven(activationConfig = {
> @ActivationConfigProperty(
> propertyName = "destinationType",
> propertyValue = "javax.jms.Queue"),
> @ActivationConfigProperty(
> propertyName = "destination",
> propertyValue = TestMDBBean.QUEUE_NAME)
> ,@ActivationConfigProperty(
> propertyName = "acknowledgeMode",
> propertyValue = "Auto-acknowledge")
> })
> //@TransactionManagement(TransactionManagementType.CONTAINER)
> @TransactionAttribute(TransactionAttributeType.REQUIRED)
> public class TestMDBBean implements MessageListener {
> public static final String QUEUE_NAME = 
> "SendReceiveQueue";//"ErrorQueue";;
> public void onMessage(Message message) {
> System.err.println("This is a test");
> throw new EJBException("This is a lovely test");
> }
> }
> open-ejbjar.xml
> 
>  xmlns="http://www.openejb.org/xml/ns/openejb-jar-2.1";
> xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.1";
> xmlns:security="http://geronimo.apache.org/xml/ns/security-1.1";
> xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.1";
> xmlns:pkgen="http://www.openejb.org/xml/ns/pkgen-2.0";>
> 
> 
> TestMDBBean
> 
> 
> ActiveMQ RA
> 
> 
> 
> 
> Geronimo application
> 
>  xmlns="http://geronimo.apache.org/xml/ns/j2ee/application-1.2";
> xmlns:security="http://geronimo.apache.org/xml/ns/security-1.2

Re: [ANNOUNCE] Lin Sun is the newest member of the Geronimo PMC

2008-06-27 Thread Manu George

Congrats Lin

On Fri, Jun 27, 2008 at 2:14 PM, Lei Wang <[EMAIL PROTECTED]> wrote:
> Lin, congratulations!
>
> Rex
>
> 2008/6/27 Jarek Gawor <[EMAIL PROTECTED]>:
>>
>> All,
>>
>> Please join us in congratulating Lin Sun as the newest member of the
>> Geronimo PMC. She has been involved with the Geronimo community for a
>> long time and made great contributions as a committer and otherwise.
>> She will be a great addition to the PMC.
>>
>> Congratulations Lin!
>>
>> The Apache Geronimo PMC
>
>

[jira] Issue Comment Edited: (GERONIMO-4153) Messages are not being redelivered correctly


[ 
https://issues.apache.org/jira/browse/GERONIMO-4153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608709#action_12608709
 ] 

imy30 edited comment on GERONIMO-4153 at 6/27/08 2:28 AM:
---

Example source code has been enclosed. 

I have set the redelivery count in the JMS plan to 
20
This does work, because if I keep restarting the server it will slowly get upto 
20.

However even if I leave this out the default redelivery is 5 or 10, which at 
the moment it doesnt get to unless I restart the server.

  was (Author: imy30):
Example source code
  
> Messages are not being redelivered correctly
> 
>
> Key: GERONIMO-4153
> URL: https://issues.apache.org/jira/browse/GERONIMO-4153
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: ActiveMQ
>Affects Versions: 2.1, 2.1.1
> Environment: Geronimo 2.1.1, Windows XP SP3. Java 1.6_0_6
>Reporter: Mohammed Imran
> Attachments: javaEEApplication.ear, src.zip
>
>
> I am experiencing problems with redelivery of messages in activemq/geronimo 
> it seems to not redeliver the message when a system exception occurs. I know 
> that ActiveMQ has a max redelivery count, however the messages seem to stop 
> being processed after 1-2 attempts. I am not getting anywhere near the max 
> redelivery count.
> I enclose a very simple example. This ear simple has 1 MDB which will 
> automatically throw an EJBException. (In the source code I have configured it 
> to use ActiveMQ default queues and connection factory this was only done so 
> you can quickly see what happens without setting up your own queue and 
> connection factory. I also enclose a runnable class which will send a message 
> to the queue.)
> The expected result should be MDB retires 5/10/xxx amount of times whatever 
> the max redelivery count is set to and then stops redelivering the message. 
> However as I have said earlier on I am not getting this, seems to only retry 
> once.
> package test;
> import javax.ejb.*;
> import javax.jms.MessageListener;
> import javax.jms.Message;
> @MessageDriven(activationConfig = {
> @ActivationConfigProperty(
> propertyName = "destinationType",
> propertyValue = "javax.jms.Queue"),
> @ActivationConfigProperty(
> propertyName = "destination",
> propertyValue = TestMDBBean.QUEUE_NAME)
> ,@ActivationConfigProperty(
> propertyName = "acknowledgeMode",
> propertyValue = "Auto-acknowledge")
> })
> //@TransactionManagement(TransactionManagementType.CONTAINER)
> @TransactionAttribute(TransactionAttributeType.REQUIRED)
> public class TestMDBBean implements MessageListener {
> public static final String QUEUE_NAME = 
> "SendReceiveQueue";//"ErrorQueue";;
> public void onMessage(Message message) {
> System.err.println("This is a test");
> throw new EJBException("This is a lovely test");
> }
> }
> open-ejbjar.xml
> 
>  xmlns="http://www.openejb.org/xml/ns/openejb-jar-2.1";
> xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.1";
> xmlns:security="http://geronimo.apache.org/xml/ns/security-1.1";
> xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.1";
> xmlns:pkgen="http://www.openejb.org/xml/ns/pkgen-2.0";>
> 
> 
> TestMDBBean
> 
> 
> ActiveMQ RA
> 
> 
> 
> 
> Geronimo application
> 
>  xmlns="http://geronimo.apache.org/xml/ns/j2ee/application-1.2";
> xmlns:security="http://geronimo.apache.org/xml/ns/security-1.2";
> xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.2"; 
> application-name="My">
> 
> 
> tester
> mdb
> 1
> car
> 
> 
> 
> 
> org.apache.geronimo.configs
> activemq-ra
> 2.1.1
> car
> 
> 
> 
> 
> 
> 
> 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-4153) Messages are not being redelivered correctly


 [ 
https://issues.apache.org/jira/browse/GERONIMO-4153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mohammed Imran updated GERONIMO-4153:
-

Attachment: src.zip

Example source code

> Messages are not being redelivered correctly
> 
>
> Key: GERONIMO-4153
> URL: https://issues.apache.org/jira/browse/GERONIMO-4153
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: ActiveMQ
>Affects Versions: 2.1, 2.1.1
> Environment: Geronimo 2.1.1, Windows XP SP3. Java 1.6_0_6
>Reporter: Mohammed Imran
> Attachments: javaEEApplication.ear, src.zip
>
>
> I am experiencing problems with redelivery of messages in activemq/geronimo 
> it seems to not redeliver the message when a system exception occurs. I know 
> that ActiveMQ has a max redelivery count, however the messages seem to stop 
> being processed after 1-2 attempts. I am not getting anywhere near the max 
> redelivery count.
> I enclose a very simple example. This ear simple has 1 MDB which will 
> automatically throw an EJBException. (In the source code I have configured it 
> to use ActiveMQ default queues and connection factory this was only done so 
> you can quickly see what happens without setting up your own queue and 
> connection factory. I also enclose a runnable class which will send a message 
> to the queue.)
> The expected result should be MDB retires 5/10/xxx amount of times whatever 
> the max redelivery count is set to and then stops redelivering the message. 
> However as I have said earlier on I am not getting this, seems to only retry 
> once.
> package test;
> import javax.ejb.*;
> import javax.jms.MessageListener;
> import javax.jms.Message;
> @MessageDriven(activationConfig = {
> @ActivationConfigProperty(
> propertyName = "destinationType",
> propertyValue = "javax.jms.Queue"),
> @ActivationConfigProperty(
> propertyName = "destination",
> propertyValue = TestMDBBean.QUEUE_NAME)
> ,@ActivationConfigProperty(
> propertyName = "acknowledgeMode",
> propertyValue = "Auto-acknowledge")
> })
> //@TransactionManagement(TransactionManagementType.CONTAINER)
> @TransactionAttribute(TransactionAttributeType.REQUIRED)
> public class TestMDBBean implements MessageListener {
> public static final String QUEUE_NAME = 
> "SendReceiveQueue";//"ErrorQueue";;
> public void onMessage(Message message) {
> System.err.println("This is a test");
> throw new EJBException("This is a lovely test");
> }
> }
> open-ejbjar.xml
> 
>  xmlns="http://www.openejb.org/xml/ns/openejb-jar-2.1";
> xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.1";
> xmlns:security="http://geronimo.apache.org/xml/ns/security-1.1";
> xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.1";
> xmlns:pkgen="http://www.openejb.org/xml/ns/pkgen-2.0";>
> 
> 
> TestMDBBean
> 
> 
> ActiveMQ RA
> 
> 
> 
> 
> Geronimo application
> 
>  xmlns="http://geronimo.apache.org/xml/ns/j2ee/application-1.2";
> xmlns:security="http://geronimo.apache.org/xml/ns/security-1.2";
> xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.2"; 
> application-name="My">
> 
> 
> tester
> mdb
> 1
> car
> 
> 
> 
> 
> org.apache.geronimo.configs
> activemq-ra
> 2.1.1
> car
> 
> 
> 
> 
> 
> 
> 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-4153) Messages are not being redelivered correctly