[jira] Closed: (GERONIMO-4189) Enable Geronimo Eclipse Plug-in (GEP) to get dynamic information from server

[Shiva Kumar H R (JIRA)]

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

Shiva Kumar H R closed GERONIMO-4189.
-

Resolution: Invalid

> Enable Geronimo Eclipse Plug-in (GEP) to get dynamic information from server
> 
>
> Key: GERONIMO-4189
> URL: https://issues.apache.org/jira/browse/GERONIMO-4189
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: PlanCreator
>Affects Versions: 2.2
>Reporter: Shiva Kumar H R
>Assignee: Shiva Kumar H R
> Fix For: 2.2
>
>
> For intuitive creation/editing of Geronimo Deployment Plans inside GEP 
> Deployment Plan Editors, GEP must be able to query the server for deployed 
> resources (GERONIMODEVTOOLS-425). One of the ways of accomplishing this 
> (thanks to Vamsi for the idea!) is as below:
> 1. Have a Servlet deployed & running on the server, that can issue GBean 
> queries to fetch the required dynamic info from the server (like deployed 
> EJBs, JDBC Connection Pools, JMS Connection Factories & Destinations, Java 
> Mail Sessions, Credential Stores, Common Libs & Security Realms) and pass 
> this info to the caller may be as a binary object.
> 2. Inside GEP, invoke the above Servlet with required arguments to get the 
> dynamic info.

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

[jira] Commented: (GERONIMO-4189) Enable Geronimo Eclipse Plug-in (GEP) to get dynamic information from server

[Shiva Kumar H R (JIRA)]

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

Shiva Kumar H R commented on GERONIMO-4189:
---

GERONIMODEVTOOLS-434 shows how GEP can get the required dynamic information 
from Server using JMX (neat approach), instead of the earlier approach of 
having a dedicated Servlet deployed on the system.

Hence the changes that were earlier made in revision: 675220 have been reverted 
at revision: 677509.

Thanks to Jarek for capturing this, and to Sainath for figuring out how to use 
JMX to get the required dynamic info.

> Enable Geronimo Eclipse Plug-in (GEP) to get dynamic information from server
> 
>
> Key: GERONIMO-4189
> URL: https://issues.apache.org/jira/browse/GERONIMO-4189
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: PlanCreator
>Affects Versions: 2.2
>Reporter: Shiva Kumar H R
>Assignee: Shiva Kumar H R
> Fix For: 2.2
>
>
> For intuitive creation/editing of Geronimo Deployment Plans inside GEP 
> Deployment Plan Editors, GEP must be able to query the server for deployed 
> resources (GERONIMODEVTOOLS-425). One of the ways of accomplishing this 
> (thanks to Vamsi for the idea!) is as below:
> 1. Have a Servlet deployed & running on the server, that can issue GBean 
> queries to fetch the required dynamic info from the server (like deployed 
> EJBs, JDBC Connection Pools, JMS Connection Factories & Destinations, Java 
> Mail Sessions, Credential Stores, Common Libs & Security Realms) and pass 
> this info to the caller may be as a binary object.
> 2. Inside GEP, invoke the above Servlet with required arguments to get the 
> dynamic info.

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

Re: Liferay as a Geronimo Plugin

[Gianny Damour]

On 14/07/2008, at 5:17 PM, Peter Petersson wrote:


Gianny Damour wrote:

Hello Peter,

This is great news for Liferay developers!

IMHO, one of the pain points with Liferay development is the time  
it takes to build, pack and deploy a WAR to Liferay. Even if  
Liferay is not so bad on this front when compared with other  
portals, a typical build-deploy-test cycle is way too time  
consuming and hence seriously impacts productivity. It would be  
fantastic to have an in-place WAR development mode in Geronimo.  
What do you think?
I guess you are referring to working with/in the liferay ext  
development environment (?). I know to little of Liferay internals  
(and Geronimo for that mater) to be sure exactly what you are  
looking for, but I am sure the Liferay team is working hard on  
making there development environment easier and faster to work  
with. Maybe you can elaborate a bit more on what you are thinking of.

Hello,

My understanding is that each time that you make a change, you need  
to build a WAR; drop it in the deployment folder of Liferay; Liferay  
scans and transforms the WAR (looking for portlets, themes et  
cetera); it then hands it over to Geronimo for deployment. These  
deployment steps are time consuming, especially during development.


What I had in mind is a Geronimo plugin allowing the in-place  
deployment of WARs to Liferay:

1. I define a specific WAR project structure;
2. I set-up my IDE to work against this well-known WAR project  
structure;
3. I implement my portlets and my IDE compiles the sources to the  
right folder of the WAR project structure;

4. I deploy to Geronimo my WAR project structure;
5. A custom ModuleBuilder identifies that this is a liferay WAR  
project structure; looks for the relevant Liferay components; and  
deploys it in-place.





Personally I will look in to setting up a maven project for  
building Liferay portlets and have them deployed to Geronimo in  
some automated way instead of working with the ext environment,  
maybe this is what you are looking for? I don't know yet how the  
deployment could be done but I guess that I will making use of  
Liferays hot-deploy mechanism and/or if possible find some way to  
make use of Geronimo:s plugin concept. If possible I would  
certainly prefer the plugin solution.


I believe that the Liferay hot-deployment mechanism is way too slow  
in development.


Does that make sense?

Thanks,
Gianny



Maybe the deployment could be done in a similar way of what we have  
done with the roller-themes plugin in the geromimo-roller project ?

see https://svn.apache.org/repos/asf/geronimo/plugins/roller/trunk

regards
  peter petersson



Thanks,
Gianny

On 14/07/2008, at 4:11 AM, Peter Petersson wrote:



I have posted a feature issue containing the build code over at  
http://support.liferay.com/browse/LEP-6680

regards
  peter petersson

Peter Petersson wrote:

Hi

With the help of David J custom server assemblies document  
( http://cwiki.apache.org/GMOxDOC21/custom-server- 
assemblies.html ) and my experience working with David on the  
roller plugin I have manage to put together a Liferay ( http:// 
www.liferay.com ) plugin. For now the plugin is with liferay  
5.0.1 rc1 on G 2.1.1 and consists of the following maven artifacts


* geronimo-jetty-liferay -- A minimalistic server assembly with  
the geronimo kernel the lifray jetty plugin and the geronimo  
console plugin.
* liferay-jetty -- The liferay jetty plugin built on the  
lesslibs liferay-portal war pulling in dependencys like lifray - 
kernel, -service and -portlet.
* geronimo-tomcat-liferay -- A minimalistic server as above but  
with the liferay tomcat plugin.
* liferay-tomcat -- The liferay tomcat plugin as liferay-jetty  
above but with tomcat.

* liferay-derby -- The liferay derby db backend plugin.
* lifray-portal -- The liferay portal war fetched from liferay  
and pulled in to a local maven repos.
* liferay-portal-lesslibs -- A overlay of the liferay portal war  
with filtered lib jars making use of some geronimo builtins  
instead.


The geronimo-tomcat-liferay server seems to work fine but the  
jetty equivalent has a issue in the login page. When I have  
ironed out the jetty issue, cleaned up the code, made some  
additional improvements and put together a simple readme with  
build instructions ;) I am thinking of wrapping it up and first  
of all contribute it to the liferay community ( as suggested by  
david in http://marc.info/?l=geronimo- 
user&m=121304343919559&w=2 ) to see if they are interested in it  
for there geronimo integration.


Anny suggestions, opinions, tips or help to pull this together  
in the best way possible are appreciated.


regards
 peter petersson

[jira] Commented: (GERONIMODEVTOOLS-402) Upgrade GEP to support Eclipse 3.4 and WTP 3.0

[Delos Dai (JIRA)]

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

Delos Dai commented on GERONIMODEVTOOLS-402:


Hi,
I have two questions about the problem.
1) I placed the devtools without patch  into eclipse 3.4 plugins directory and 
run a "dynamic web project", it works fine. So I wonder what exactly the 
situation of the issue posted in "GERONIMODEVTOOLS-432"?

2)Rev 672096 modify pom.xml,build.xml and feature.xml. I found the modification 
only cover artifact id, package name, download URL. Will this make any 
difference for the plugins? 

Thanks a lot!

> Upgrade GEP to support Eclipse 3.4 and WTP 3.0
> --
>
> Key: GERONIMODEVTOOLS-402
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-402
> Project: Geronimo-Devtools
>  Issue Type: Sub-task
>  Components: eclipse-plugin
>Reporter: Tim McConnell
>Assignee: Tim McConnell
> Fix For: 2.1.2
>
>


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

Re: svn commit: r664199 - /geronimo/samples/trunk/samples/app-per-port/app-per-port-tomcat/src/main/plan/plan.xml

[Joe Bohn]

Thanks for the input David ... answers inline.

David Jencks wrote:


On Jul 16, 2008, at 12:52 PM, Joe Bohn wrote:



David,

Can this change be merged into samples/branches/2.1 or is it dependent 
on changes in server/trunk that are not included in server/branches/2.1?


These changes definitely depend on those in rev 664198.  I'm of two 
minds about porting that back to branches/2.1.  On the one hand its 
really kind of a bug, on the other hand it is a very noticeable 
structural change  that is definitely not backward compatible.


I agree that we shouldn't rock the boat too much in a maintenance 
release.  I was really just trying to understand the problems with the 
sample and if a portion of the changes that were made in the sample for 
trunk would fix the errors I am seeing without any additional server 
changes in 2.1.  However, I am still curious as to what changed in the 
2.1 server since I know this sample wasn't getting these errors or the 
exception a few weeks ago.







Somewhere along the way the app-per-port sample started failing 
install in branches/2.1 and I was wondering if these changes 
(particularly the localhost changes) would correct the problem.


Here's the error when installing the app-per-port sample:

15:24:56,119 ERROR [JAASRealm] Class 
org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal not 
found! Class not added.
15:24:56,119 ERROR [JAASRealm] Class 
org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal 
not found! Class not added.

15:24:56,179 ERROR [ProxyCollection] Listener threw exception
java.lang.IllegalArgumentException: addChild:  Child name 'localhost' 
is not unique
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:781) 

at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
at 
org.apache.catalina.core.StandardEngine.addChild(StandardEngine.java:262)
at 
org.apache.geronimo.tomcat.EngineGBean.addHost(EngineGBean.java:182)
at 
org.apache.geronimo.tomcat.EngineGBean.access$000(EngineGBean.java:47)
at 
org.apache.geronimo.tomcat.EngineGBean$1.memberAdded(EngineGBean.java:143) 

at 
org.apache.geronimo.gbean.runtime.ProxyCollection.addTarget(ProxyCollection.java:102) 

at 
org.apache.geronimo.gbean.runtime.GBeanCollectionReference.targetAdded(GBeanCollectionReference.java:96) 

at 
org.apache.geronimo.gbean.runtime.GBeanCollectionReference.addTarget(GBeanCollectionReference.java:180) 

at 
org.apache.geronimo.gbean.runtime.GBeanCollectionReference$1.running(GBeanCollectionReference.java:110) 

at 
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176) 

at 
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44) 

at 
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254) 

at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294) 

at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) 

at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) 

at 
org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:555) 

at 
org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) 

at 
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:456) 

at 
org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:188) 

at 
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:562) 

at 
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:543) 

at 
org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:684) 

at 
org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:602) 

at 
org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:598) 

at 
org.apache.geronimo.system.plugin.PluginInstallerGBean$3.run(PluginInstallerGBean.java:749) 


at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:214)
at 
org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:344) 

at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) 

at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) 


at java.lang.Thread.run(Thread.java:613)
15:24:56,659 WARN  [MapperListener] Unknown default host: localhost


BTW, I think the JAASRealm error is new this week since I believe that 
I saw the above error without the JAASRealm errors last when when I 
attempted to deploy t

Re: svn commit: r664199 - /geronimo/samples/trunk/samples/app-per-port/app-per-port-tomcat/src/main/plan/plan.xml

[David Jencks]

On Jul 16, 2008, at 12:52 PM, Joe Bohn wrote:



David,

Can this change be merged into samples/branches/2.1 or is it  
dependent on changes in server/trunk that are not included in server/ 
branches/2.1?


These changes definitely depend on those in rev 664198.  I'm of two  
minds about porting that back to branches/2.1.  On the one hand its  
really kind of a bug, on the other hand it is a very noticeable  
structural change  that is definitely not backward compatible.




Somewhere along the way the app-per-port sample started failing  
install in branches/2.1 and I was wondering if these changes  
(particularly the localhost changes) would correct the problem.


Here's the error when installing the app-per-port sample:

15:24:56,119 ERROR [JAASRealm] Class  
org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal  
not found! Class not added.
15:24:56,119 ERROR [JAASRealm] Class  
org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal  
not found! Class not added.

15:24:56,179 ERROR [ProxyCollection] Listener threw exception
java.lang.IllegalArgumentException: addChild:  Child name  
'localhost' is not unique
	at  
org 
.apache 
.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:781)
	at  
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java: 
771)
	at  
org.apache.catalina.core.StandardEngine.addChild(StandardEngine.java: 
262)
	at org.apache.geronimo.tomcat.EngineGBean.addHost(EngineGBean.java: 
182)
	at org.apache.geronimo.tomcat.EngineGBean.access 
$000(EngineGBean.java:47)
	at org.apache.geronimo.tomcat.EngineGBean 
$1.memberAdded(EngineGBean.java:143)
	at  
org 
.apache 
.geronimo 
.gbean.runtime.ProxyCollection.addTarget(ProxyCollection.java:102)
	at  
org 
.apache 
.geronimo 
.gbean 
.runtime 
.GBeanCollectionReference.targetAdded(GBeanCollectionReference.java: 
96)
	at  
org 
.apache 
.geronimo 
.gbean 
.runtime 
.GBeanCollectionReference.addTarget(GBeanCollectionReference.java:180)
	at org.apache.geronimo.gbean.runtime.GBeanCollectionReference 
$1.running(GBeanCollectionReference.java:110)
	at  
org 
.apache 
.geronimo 
.kernel 
.basic 
.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java: 
176)
	at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access 
$300(BasicLifecycleMonitor.java:44)
	at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor 
$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java: 
254)
	at  
org 
.apache 
.geronimo 
.gbean 
.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java: 
294)
	at  
org 
.apache 
.geronimo 
.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
	at  
org 
.apache 
.geronimo 
.gbean 
.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java: 
124)
	at  
org 
.apache 
.geronimo 
.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:555)
	at  
org 
.apache 
.geronimo 
.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379)
	at  
org 
.apache 
.geronimo 
.kernel 
.config 
.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java: 
456)
	at  
org 
.apache 
.geronimo 
.kernel 
.config 
.KernelConfigurationManager.start(KernelConfigurationManager.java:188)
	at  
org 
.apache 
.geronimo 
.kernel 
.config 
.SimpleConfigurationManager 
.startConfiguration(SimpleConfigurationManager.java:562)
	at  
org 
.apache 
.geronimo 
.kernel 
.config 
.SimpleConfigurationManager 
.startConfiguration(SimpleConfigurationManager.java:543)
	at  
org 
.apache 
.geronimo 
.system 
.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:684)
	at  
org 
.apache 
.geronimo 
.system 
.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:602)
	at  
org 
.apache 
.geronimo 
.system 
.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:598)
	at org.apache.geronimo.system.plugin.PluginInstallerGBean 
$3.run(PluginInstallerGBean.java:749)

at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:214)
	at org.apache.geronimo.pool.ThreadPool 
$ContextClassLoaderRunnable.run(ThreadPool.java:344)
	at java.util.concurrent.ThreadPoolExecutor 
$Worker.runTask(ThreadPoolExecutor.java:650)
	at java.util.concurrent.ThreadPoolExecutor 
$Worker.run(ThreadPoolExecutor.java:675)

at java.lang.Thread.run(Thread.java:613)
15:24:56,659 WARN  [MapperListener] Unknown default host: localhost


BTW, I think the JAASRealm error is new this week since I believe  
that I saw the above error without the JAASRealm errors last when  
when I attempted to deploy this sample.



After applying these changes I still get these errors:
15:40:14,522 ERROR [JAASRealm] Class  
org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal  
not found! Class not added.
15:40:14,523 ERROR [JAASRealm] Class  
org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal  
not found! Class not added.
15:40:14,524 ERROR [JAASRealm] Class  
org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal  
not

[jira] Commented: (GERONIMODEVTOOLS-442) Documentation updates

[Tim McConnell (JIRA)]

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

Tim McConnell commented on GERONIMODEVTOOLS-442:


Update these website(s):

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

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


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

[jira] Created: (GERONIMODEVTOOLS-442) Documentation updates

[Tim McConnell (JIRA)]

Documentation updates
-

 Key: GERONIMODEVTOOLS-442
 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-442
 Project: Geronimo-Devtools
  Issue Type: Sub-task
Reporter: Tim McConnell
Assignee: Tim McConnell




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

Re: [jira] Updated: (GERONIMO-4131) Problems with WebSphere MQ RA deployment

[sbyonge]

I can test it for you if you put the binary build to somewhere I can pick it
up.  Or let me know how to build 2.1.2.  This is a critical bug preventing
us going forward with Geronimo.


JIRA [EMAIL PROTECTED] wrote:
> 
> 
>  [
> https://issues.apache.org/jira/browse/GERONIMO-4131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
> 
> Jarek Gawor updated GERONIMO-4131:
> --
> 
> Attachment: GERONIMO-4131.patch
> 
> Updated the patch to handle the port property (the port property has two
> setters setPort(int) and sertPort(String) so updated the code to also
> lookup the setters using the corresponding primitive type (if any)).
> 
> 
>> Problems with WebSphere MQ RA deployment
>> 
>>
>> Key: GERONIMO-4131
>> URL: https://issues.apache.org/jira/browse/GERONIMO-4131
>> Project: Geronimo
>>  Issue Type: Bug
>>  Security Level: public(Regular issues) 
>>  Components: connector
>>Affects Versions: 2.0.1, 2.0.2, 2.1, 2.1.1, 2.1.2
>>Reporter: Kevan Miller
>>Assignee: Jarek Gawor
>> Fix For: 2.1.2
>>
>> Attachments: GERONIMO-4131.patch, GERONIMO-4131.patch
>>
>>
>> A user reported problems deploying an MQ RA on Geronimo. Looks like there
>> are several problems.
>> 1) we don't like config-property-name values in ra.xml to start with a
>> lower case letter
>> 2) our mechanism for introspecting the implementation classes (e.g.
>> managedconnectionfactory-class) is not working properly. there can be
>> multiple "set" methods taking different parameter types. This is leading
>> to type-mismatches as we try to set attributes.
> 
> -- 
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/-jira--Created%3A-%28GERONIMO-4131%29-Problems-with-WebSphere-MQ-RA-deployment-tp17991183s134p18495691.html
Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.

Re: svn commit: r664199 - /geronimo/samples/trunk/samples/app-per-port/app-per-port-tomcat/src/main/plan/plan.xml

[Joe Bohn]

David,

Can this change be merged into samples/branches/2.1 or is it dependent 
on changes in server/trunk that are not included in server/branches/2.1?


Somewhere along the way the app-per-port sample started failing install 
in branches/2.1 and I was wondering if these changes (particularly the 
localhost changes) would correct the problem.


Here's the error when installing the app-per-port sample:

15:24:56,119 ERROR [JAASRealm] Class 
org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal not 
found! Class not added.
15:24:56,119 ERROR [JAASRealm] Class 
org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal not 
found! Class not added.

15:24:56,179 ERROR [ProxyCollection] Listener threw exception
java.lang.IllegalArgumentException: addChild:  Child name 'localhost' is 
not unique
	at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:781)

at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
	at 
org.apache.catalina.core.StandardEngine.addChild(StandardEngine.java:262)

at org.apache.geronimo.tomcat.EngineGBean.addHost(EngineGBean.java:182)
at 
org.apache.geronimo.tomcat.EngineGBean.access$000(EngineGBean.java:47)
	at 
org.apache.geronimo.tomcat.EngineGBean$1.memberAdded(EngineGBean.java:143)
	at 
org.apache.geronimo.gbean.runtime.ProxyCollection.addTarget(ProxyCollection.java:102)
	at 
org.apache.geronimo.gbean.runtime.GBeanCollectionReference.targetAdded(GBeanCollectionReference.java:96)
	at 
org.apache.geronimo.gbean.runtime.GBeanCollectionReference.addTarget(GBeanCollectionReference.java:180)
	at 
org.apache.geronimo.gbean.runtime.GBeanCollectionReference$1.running(GBeanCollectionReference.java:110)
	at 
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176)
	at 
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44)
	at 
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254)
	at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294)
	at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
	at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124)
	at 
org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:555)
	at 
org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379)
	at 
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:456)
	at 
org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:188)
	at 
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:562)
	at 
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:543)
	at 
org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:684)
	at 
org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:602)
	at 
org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:598)
	at 
org.apache.geronimo.system.plugin.PluginInstallerGBean$3.run(PluginInstallerGBean.java:749)

at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:214)
	at 
org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:344)
	at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
	at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)

at java.lang.Thread.run(Thread.java:613)
15:24:56,659 WARN  [MapperListener] Unknown default host: localhost


BTW, I think the JAASRealm error is new this week since I believe that I 
saw the above error without the JAASRealm errors last when when I 
attempted to deploy this sample.



After applying these changes I still get these errors:
15:40:14,522 ERROR [JAASRealm] Class 
org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal not 
found! Class not added.
15:40:14,523 ERROR [JAASRealm] Class 
org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal not 
found! Class not added.
15:40:14,524 ERROR [JAASRealm] Class 
org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal not 
found! Class not added.
15:40:14,524 ERROR [JAASRealm] Class 
org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal not 
found! Class not added.

15:40:15,132 WARN  [MapperListener] Unknown default host: localhost1
15:40:15,297 WARN  [MapperListener] Unknown default host: localhost2


... which makes me think there are changes missing from 
server/branches/2.1 for the localhost change.


Joe


[EMAIL PROTECTED] wrote:

Author: djencks
Date: Fri Jun  6 16:43:39 2008
New Revision: 664199

[jira] Resolved: (GERONIMO-4187) setManagerClassName has been deprecated for the SimpleTCPCluster class in Tomcat Clustering

[Jason Warner (JIRA)]

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

Jason Warner resolved GERONIMO-4187.


Resolution: Fixed

fix committed to trunk in revision 677382

> setManagerClassName has been deprecated for the SimpleTCPCluster class in 
> Tomcat Clustering
> ---
>
> Key: GERONIMO-4187
> URL: https://issues.apache.org/jira/browse/GERONIMO-4187
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Clustering
>Affects Versions: 2.2
>Reporter: Jason Warner
>Assignee: Jason Warner
> Fix For: 2.2
>
>
> Currently when configuring tomcat clustering in geronimo, the manager class 
> name for the cluster is passed through as an init parameter and is set using 
> the setManagerClassName method.  This method has been deprecated in Tomcat 6 
> and an alternate method of setting the manager has been introduced.  The 
> manager can now be set as a subelement of the cluster element in the 
> configuration.  Geronimo should switch to this new method of configuring a 
> manager so that we're better poised to maintain compatibility with future 
> tomcat releases.  

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

Re: Geronimo trunk build failure with fresh OpenEjb trunk build

[David Jencks]

On Jul 16, 2008, at 11:10 AM, David Blevins wrote:



On Jul 16, 2008, at 10:43 AM, David Blevins wrote:



On Jul 16, 2008, at 3:39 AM, Rick McGuire wrote:


David Blevins wrote:


On Jul 15, 2008, at 10:55 AM, Rick McGuire wrote:

I just committed this change.  It doesn't look like this is  
causing any tck issues.


Guessing a lot of those places you added the 3.1 api were more or  
less "just in case".  You definitely shouldn't need it in any  
modules that don't directly use the new ejb 3.1 API (thinking of  
the test suite and mejb).
Unfortunately, not true.  Any code that used the annotation  
deployer either directly or indirectly got the same error.  mejb,  
in fact, was the first place that got hit after I applied the two  
changes you recommended.  The direct references to the Singleton  
class were causing the issue.  After fixing mejb, it started to  
turn into a game of "whack-a-mole", so ended up doing a blanket  
add wherever the ejb 3.0 specs were used.


That's so weird.  OpenEJB needs a lot more dependencies that for  
some reason don't have to be declared in all those little modules.   
We have to be missing something.


This might also be a hack, but we could maybe add it to the plugins/ 
openejb/geronimo-openejb/src/main/resources/META-INF/geronimo- 
dependency.xml and get it into the system that way.


geronimo-dependencies.xml seems to mostly confuse people and I thought  
I'd eliminated all of them.  I think a better approach is to use the  
maven dependencies in the geronimo plugin module.  We can now set up  
the c-m-p to use transitive dependencies and maybe this would be a  
good test case for how well we can make this work (so far it's only  
used in the gshell plugins AFAIK)


Anyway geronimo-dependencies.xml is unknown to maven classloaders  
not sure exactly what the problems you are dealing with here are...


thanks
david jencks




-David




Rick


-David


Joe Bohn wrote:


Rick McGuire wrote:

David Blevins wrote:


On Jul 10, 2008, at 1:17 PM, Joe Bohn wrote:

If I build Geronimo trunk using the latest OpenEjb snapshots  
(published around 6/27-28) things build fine.  However, if I  
grab OpenEjb trunk and build it locally (to get the latest  
image) I get build failures (NoClassDefFoundError) in the  
Geronimo MEJB config.  I suspect we need to make some  
changes to accommodate the Singleton Session Beans  
implementation.  Is this complete yet and is anybody looking  
into the necessary Geronimo changes?


We'd need to get this dep in the right place if we wanted to  
keep using OpenEJB trunk:



  org.apache.openejb
  ejb31-api-experimental
  ${openejbVersion}


These two poms seem to be the only places where the ejb 3.0  
spec jar is used:


./framework/configs/jee-specs/pom.xml
./framework/modules/geronimo-j2ee/pom.xml

I'm fine giving it a shot if no one objects to being  
dependent on a non-final spec jar.  We might try it out and  
see if the tck complains at least.
I needed to do this to get a clean build using the latest, and  
it's a lot more than just those two poms that needed  
updating.  I'm going to try doing some tck runs to see how  
things look.


Rick



Hi Rick,  Is this at a point where you can check it in?   
Everybody is hitting the trunk build break now that new openejb  
snapshots have been published.


Thanks,
Joe








-David


---
[INFO] Building Geronimo Plugins, MEJB :: Config
[INFO]task-segment: [install]
[INFO]  


[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:validate-configuration]
[INFO] [car:prepare-plan]
[INFO] Generated: /home/jbohn/geronimo/plugins/mejb/mejb/ 
target/resources/META-INF/plan.xml

[INFO] [car:package]
[INFO] Packaging module configuration: /home/jbohn/geronimo/ 
plugins/mejb/mejb/target/resources/META-INF/plan.xml
[INFO] Started deployer: org.apache.geronimo.framework/ 
geronimo-gbean-deployer/2.2-SNAPSHOT/car
[INFO] Started deployer: org.apache.geronimo.configs/openejb- 
deployer/2.2-SNAPSHOT/car
14:13:36,387 INFO  [config] Configuring Service(id=Default  
Stateless Container, type=Container, provider-id=Default  
Stateless Cont

ainer)
14:13:36,392 INFO  [config] Configuring Service(id=Default  
Stateful Container, type=Container, provider-id=Default  
Stateful Contai

ner)
14:13:36,393 INFO  [config] Configuring Service(id=Default  
BMP Container, type=Container, provider-id=Default BMP  
Container)
14:13:36,394 INFO  [config] Configuring Service(id=Default  
CMP Container, type=Container, provider-id=Default CMP  
Container)
14:13:36,402 INFO  [config] Configuring enterprise  
application: org.apache.geronimo.configs/mejb/2.2-SNAPSHOT/car

[ERROR] Deployment failed due to
java.lang.NoClassDefFoundError: java

Re: Geronimo trunk build failure with fresh OpenEjb trunk build

[David Blevins]

On Jul 16, 2008, at 10:43 AM, David Blevins wrote:



On Jul 16, 2008, at 3:39 AM, Rick McGuire wrote:


David Blevins wrote:


On Jul 15, 2008, at 10:55 AM, Rick McGuire wrote:

I just committed this change.  It doesn't look like this is  
causing any tck issues.


Guessing a lot of those places you added the 3.1 api were more or  
less "just in case".  You definitely shouldn't need it in any  
modules that don't directly use the new ejb 3.1 API (thinking of  
the test suite and mejb).
Unfortunately, not true.  Any code that used the annotation  
deployer either directly or indirectly got the same error.  mejb,  
in fact, was the first place that got hit after I applied the two  
changes you recommended.  The direct references to the Singleton  
class were causing the issue.  After fixing mejb, it started to  
turn into a game of "whack-a-mole", so ended up doing a blanket add  
wherever the ejb 3.0 specs were used.


That's so weird.  OpenEJB needs a lot more dependencies that for  
some reason don't have to be declared in all those little modules.   
We have to be missing something.


This might also be a hack, but we could maybe add it to the plugins/ 
openejb/geronimo-openejb/src/main/resources/META-INF/geronimo- 
dependency.xml and get it into the system that way.


-David




Rick


-David


Joe Bohn wrote:


Rick McGuire wrote:

David Blevins wrote:


On Jul 10, 2008, at 1:17 PM, Joe Bohn wrote:

If I build Geronimo trunk using the latest OpenEjb snapshots  
(published around 6/27-28) things build fine.  However, if I  
grab OpenEjb trunk and build it locally (to get the latest  
image) I get build failures (NoClassDefFoundError) in the  
Geronimo MEJB config.  I suspect we need to make some changes  
to accommodate the Singleton Session Beans implementation.   
Is this complete yet and is anybody looking into the  
necessary Geronimo changes?


We'd need to get this dep in the right place if we wanted to  
keep using OpenEJB trunk:


 
   org.apache.openejb
   ejb31-api-experimental
   ${openejbVersion}
 

These two poms seem to be the only places where the ejb 3.0  
spec jar is used:


./framework/configs/jee-specs/pom.xml
./framework/modules/geronimo-j2ee/pom.xml

I'm fine giving it a shot if no one objects to being dependent  
on a non-final spec jar.  We might try it out and see if the  
tck complains at least.
I needed to do this to get a clean build using the latest, and  
it's a lot more than just those two poms that needed updating.   
I'm going to try doing some tck runs to see how things look.


Rick



Hi Rick,  Is this at a point where you can check it in?   
Everybody is hitting the trunk build break now that new openejb  
snapshots have been published.


Thanks,
Joe








-David


---
[INFO] Building Geronimo Plugins, MEJB :: Config
[INFO]task-segment: [install]
[INFO]  


[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:validate-configuration]
[INFO] [car:prepare-plan]
[INFO] Generated: /home/jbohn/geronimo/plugins/mejb/mejb/ 
target/resources/META-INF/plan.xml

[INFO] [car:package]
[INFO] Packaging module configuration: /home/jbohn/geronimo/ 
plugins/mejb/mejb/target/resources/META-INF/plan.xml
[INFO] Started deployer: org.apache.geronimo.framework/ 
geronimo-gbean-deployer/2.2-SNAPSHOT/car
[INFO] Started deployer: org.apache.geronimo.configs/openejb- 
deployer/2.2-SNAPSHOT/car
14:13:36,387 INFO  [config] Configuring Service(id=Default  
Stateless Container, type=Container, provider-id=Default  
Stateless Cont

ainer)
14:13:36,392 INFO  [config] Configuring Service(id=Default  
Stateful Container, type=Container, provider-id=Default  
Stateful Contai

ner)
14:13:36,393 INFO  [config] Configuring Service(id=Default  
BMP Container, type=Container, provider-id=Default BMP  
Container)
14:13:36,394 INFO  [config] Configuring Service(id=Default  
CMP Container, type=Container, provider-id=Default CMP  
Container)
14:13:36,402 INFO  [config] Configuring enterprise  
application: org.apache.geronimo.configs/mejb/2.2-SNAPSHOT/car

[ERROR] Deployment failed due to
java.lang.NoClassDefFoundError: javax/ejb/Singleton
org.apache.openejb.config.AnnotationDeployer 
$DiscoverAnnotatedBeans.deploy(AnnotationDeployer.java:339)
org.apache.openejb.config.AnnotationDeployer 
$DiscoverAnnotatedBeans.deploy(AnnotationDeployer.java:230)
org 
.apache 
.openejb 
.config.AnnotationDeployer.deploy(AnnotationDeployer.java:174)
org.apache.openejb.config.ConfigurationFactory 
$Chain.deploy(ConfigurationFactory.java:228)
org 
.apache 
.openejb 
.config 
.ConfigurationFactory 
.configureApplication(ConfigurationFactory.java:584)
org 
.apache 
.geronimo 
.openejb 
.deployment 
.EjbModuleBuilder.configureApplication(Ejb

Re: Download and Install in Geronimo Eclipse Plugin

[Ted Kirby]

That is an interesting article.  It seems to have come out when
features were new, but still has good explanatory material.  GEP has
several features, site.xml and updatesite.zip built by maven, and an
update site.  In my view, the question is do we have features for 2.1,
2.1.1 and 2.1.2 versions of Geronimo, or do we stick with v2.1 being
the latest version, and implement a new screen that would determine
all the instances of 2.1, along with the size and license of each?
Using features would be easier in terms of replicating what we have
now.  With our own screen, we could (should be able to) determine
license and size dynamically for each version.  GERONIMODEVTOOLS-416
could be done initially to get a screen in that displays licenses and
allows for click thru.  This could be used with the current approach,
and the feature approach.  For the doing our own screen approach, this
would/could be a first step.

Ted

On Wed, Jul 16, 2008 at 10:12 AM, Ashish Jain <[EMAIL PROTECTED]> wrote:
> Hi Ted,
> Thanks for your comments! Yes the license does not pop up now. I had a look
> at one of the tutorial on eclipse.org
> http://www.eclipse.org/articles/Article-Update/keeping-up-to-date.html which
> is on creating a update site. Just wondering if this can somehow fit in
> GERONIMODEVTOOLS-416 not sure though.
> Regarding creating a feature I am still looking into and will post my
> findings soon onto JIRA. Let us have more discussion on 2) and move on
> accordingly.
>
> Thanks
> Ashish
>
> On Tue, Jul 15, 2008 at 8:17 PM, Ted Kirby <[EMAIL PROTECTED]> wrote:
>>
>> On Tue, Jul 15, 2008 at 7:07 AM, Ashish Jain <[EMAIL PROTECTED]> wrote:
>> > Hi All!
>> > I would like to work on the Download and Install in GEP. Currently I do
>> > not
>> > find it intuitive and seems confusing. There are some issues with it
>> > which
>> > are as follows
>> >
>> > 1) Before Selecting "Download and Install" we need to mention a
>> > directory
>> > else the Download and Install Button will not be enabled. In this case
>> > we
>> > need to manually create a directory.
>>
>> Yes, this screen and button are not the most intuitive.  But, it does
>> provide good function.  There is a browse button next to the
>> application server installation directory text box.  In the browse
>> button dialog, there is a button/facility to create a new directory.
>>
>> > 2) Download and Install always installs the latest version of 2.x.x
>> > branch.
>> > Currently by default 2.1.2 is downloaded. In case we want to download
>> > 2.1 or
>> > 2.1.1 that does not seems to be working.
>>
>> An interesting idea.  Note also GERONIMODEVTOOLS-416 "Add
>> click-through license screen to Download and Install path" which
>> should come first and be factored in, here particularly.  in
>> addInstallableRuntimeSection in GeronimoRuntimeWizardFragment,
>> installable.getLicense(monitor) can be used to get the license from a
>> feature.  Note I recently defined v20 and v21 features.  See
>> GERONIMODEVTOOLS-417 "Create a separate installable runtime feature
>> for each version and type of geronimo server".  Were you going to
>> create a feature for each, or roll your own code?  If the latter, then
>> getLicense would probably not help here.
>
>
>>
>>
>> > 3) Sizes of the various modules being installed are manually set
>> > currently.
>> > Probably we can automate it. There is a JIRA also open for it
>> > GERONIMODEVTOOLS-403.
>>
>> I think automation would be great!
>>
>> > Regarding this we can modify the Download and Install menu as follows
>> >  Enable the button without entering the "Installation Directory". Once
>> > "Download and Install" is selected it should pop up another menu showing
>> > the
>> > different servers available for a particular version. Suppose We select
>> > Apache geronimo Server V2.1 it should enlist 2.1, 2.1.1,
>> > 2.1.2(identifying
>> > 2.1.2 as an unstable release since it is yet not released). Also in the
>> > same
>> > window we can have specify the installation directory path to install
>> > the
>> > server. If the directory is not present GEP will automatically create
>> > the
>> > directory. Select Ok to start installation.
>>
>> The current code tells you if the directory exists or not.  It seems
>> that some feedback or confirmation is desirable as opposed to blindly
>> creating a non-existent directory.
>>
>> > If there are no concerns, I would like to go ahead and implement the
>> > above
>> > features, and attach patches. Please suggest.
>>
>> As noted before, be sure to consider GERONIMODEVTOOLS-416.
>>
>> 3) has two JIRAs: 403 and 420.  It seems like 2) could be a new JIRA.
>> Anything for 1) seems a fallout of 2).  I'd like to see some
>> discussion of these issues before creating the new JIRA.
>>
>> Ted
>>
>> > Thanks
>> > Ashish
>> >
>> >
>
>

[jira] Commented: (GERONIMODEVTOOLS-235) Plugin cannot synchronize with the server when non-zero portOffset value in the config-substitutions.properties file

[Ted Kirby (JIRA)]

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

Ted Kirby commented on GERONIMODEVTOOLS-235:


See GERONIMODEVTOOLS-353 for remote server support.  While there may be 
instances where reading server config information may not work (as stated 
above), it seems that it should work in the most predominate case of local 
server.  It also seems that GeronimoServerDelegate.setDefaults is where the 
1099 and 8080 settings come from initially when defining a server, and they are 
hard-coded values.  So it seems that anything we can do to better set these 
values is a good thing.  We might put a note on the screen if we find settings 
that suggest the values should be other than these defaults.

> Plugin cannot synchronize with the server when non-zero portOffset value in 
> the config-substitutions.properties file
> 
>
> Key: GERONIMODEVTOOLS-235
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-235
> Project: Geronimo-Devtools
>  Issue Type: Bug
>  Components: eclipse-plugin
>Affects Versions: 2.0.0
>Reporter: Tim McConnell
>Assignee: Ashish Jain
> Fix For: 2.1.x
>
>


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

Re: Geronimo trunk build failure with fresh OpenEjb trunk build

[David Blevins]

On Jul 16, 2008, at 3:39 AM, Rick McGuire wrote:


David Blevins wrote:


On Jul 15, 2008, at 10:55 AM, Rick McGuire wrote:

I just committed this change.  It doesn't look like this is  
causing any tck issues.


Guessing a lot of those places you added the 3.1 api were more or  
less "just in case".  You definitely shouldn't need it in any  
modules that don't directly use the new ejb 3.1 API (thinking of  
the test suite and mejb).
Unfortunately, not true.  Any code that used the annotation deployer  
either directly or indirectly got the same error.  mejb, in fact,  
was the first place that got hit after I applied the two changes you  
recommended.  The direct references to the Singleton class were  
causing the issue.  After fixing mejb, it started to turn into a  
game of "whack-a-mole", so ended up doing a blanket add wherever the  
ejb 3.0 specs were used.


That's so weird.  OpenEJB needs a lot more dependencies that for some  
reason don't have to be declared in all those little modules.  We have  
to be missing something.


-David





Rick


-David


Joe Bohn wrote:


Rick McGuire wrote:

David Blevins wrote:


On Jul 10, 2008, at 1:17 PM, Joe Bohn wrote:

If I build Geronimo trunk using the latest OpenEjb snapshots  
(published around 6/27-28) things build fine.  However, if I  
grab OpenEjb trunk and build it locally (to get the latest  
image) I get build failures (NoClassDefFoundError) in the  
Geronimo MEJB config.  I suspect we need to make some changes  
to accommodate the Singleton Session Beans implementation.  Is  
this complete yet and is anybody looking into the necessary  
Geronimo changes?


We'd need to get this dep in the right place if we wanted to  
keep using OpenEJB trunk:


  
org.apache.openejb
ejb31-api-experimental
${openejbVersion}
  

These two poms seem to be the only places where the ejb 3.0  
spec jar is used:


./framework/configs/jee-specs/pom.xml
./framework/modules/geronimo-j2ee/pom.xml

I'm fine giving it a shot if no one objects to being dependent  
on a non-final spec jar.  We might try it out and see if the  
tck complains at least.
I needed to do this to get a clean build using the latest, and  
it's a lot more than just those two poms that needed updating.   
I'm going to try doing some tck runs to see how things look.


Rick



Hi Rick,  Is this at a point where you can check it in?   
Everybody is hitting the trunk build break now that new openejb  
snapshots have been published.


Thanks,
Joe








-David


---
[INFO] Building Geronimo Plugins, MEJB :: Config
[INFO]task-segment: [install]
[INFO]  


[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:validate-configuration]
[INFO] [car:prepare-plan]
[INFO] Generated: /home/jbohn/geronimo/plugins/mejb/mejb/ 
target/resources/META-INF/plan.xml

[INFO] [car:package]
[INFO] Packaging module configuration: /home/jbohn/geronimo/ 
plugins/mejb/mejb/target/resources/META-INF/plan.xml
[INFO] Started deployer: org.apache.geronimo.framework/ 
geronimo-gbean-deployer/2.2-SNAPSHOT/car
[INFO] Started deployer: org.apache.geronimo.configs/openejb- 
deployer/2.2-SNAPSHOT/car
14:13:36,387 INFO  [config] Configuring Service(id=Default  
Stateless Container, type=Container, provider-id=Default  
Stateless Cont

ainer)
14:13:36,392 INFO  [config] Configuring Service(id=Default  
Stateful Container, type=Container, provider-id=Default  
Stateful Contai

ner)
14:13:36,393 INFO  [config] Configuring Service(id=Default BMP  
Container, type=Container, provider-id=Default BMP Container)
14:13:36,394 INFO  [config] Configuring Service(id=Default CMP  
Container, type=Container, provider-id=Default CMP Container)
14:13:36,402 INFO  [config] Configuring enterprise  
application: org.apache.geronimo.configs/mejb/2.2-SNAPSHOT/car

[ERROR] Deployment failed due to
java.lang.NoClassDefFoundError: javax/ejb/Singleton
org.apache.openejb.config.AnnotationDeployer 
$DiscoverAnnotatedBeans.deploy(AnnotationDeployer.java:339)
org.apache.openejb.config.AnnotationDeployer 
$DiscoverAnnotatedBeans.deploy(AnnotationDeployer.java:230)
org 
.apache 
.openejb 
.config.AnnotationDeployer.deploy(AnnotationDeployer.java:174)
org.apache.openejb.config.ConfigurationFactory 
$Chain.deploy(ConfigurationFactory.java:228)
org 
.apache 
.openejb 
.config 
.ConfigurationFactory 
.configureApplication(ConfigurationFactory.java:584)
org 
.apache 
.geronimo 
.openejb 
.deployment 
.EjbModuleBuilder.configureApplication(EjbModuleBuilder.java: 
645)

[jira] Updated: (GERONIMODEVTOOLS-441) Retrieving Metadata complete Deployment Descriptor for Web Projects

[Tim McConnell (JIRA)]

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

Tim McConnell updated GERONIMODEVTOOLS-441:
---

Assignee: Tim McConnell

> Retrieving Metadata complete Deployment Descriptor for Web Projects
> ---
>
> Key: GERONIMODEVTOOLS-441
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-441
> Project: Geronimo-Devtools
>  Issue Type: Sub-task
>  Components: eclipse-plugin
>Affects Versions: 2.1.2, 2.1.x
>Reporter: Sainath Chowdary
>Assignee: Tim McConnell
> Fix For: 2.1.2, 2.1.x
>
> Attachments: DeploymentDescriptor.patch
>
>
> Another critical aspect for porting plan creator work in GEP is to retrieve 
> the metadata complete deployment descriptor. This also links the deployment 
> descriptor and deployment plan effectively.
> This should emphasize at creating an architecture so that it can be easily 
> extended for other type of projects like EJBs, EARs etc. 

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

Re: GEP should link deployment plan and deployment descriptor

[Tim McConnell]

Hi Sainath, thanks very much for working on this. I'll review your patch later 
today or tomorrow...


Sainath Chowdary wrote:

Hi,

I completed the part of obtaining metadata complete information from 
Deployment Descriptors of Web Projects. I have attached a patch to the 
following JIRA for the same.

https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-441

The new deployment descriptor classes are designed in such a way that it 
can be easily extended for other types of deployment descriptors. 
"AbstractDeploymentDescriptor" which is the parent for all other types 
stores the metadata complete descriptor as "Object" type.
As J2EE and JavaEE webapp's are two totally complete unrelated classes 
(atleast according to eclipse jst implementation), I created a interface 
in our case "WebDeploymentDescriptor" which will be implemented by both 
J2EE and JavaEE descriptor. So,Our future classes for EJBs can extend 
AbstractDeploymentDescriptor and implement a EjbDeploymentDescriptor 
which would be common for both J2EE and JavaEE EJB types.


Also a utility class is created which returns the abstract deployment 
descriptor object properly initialized based on the type of project. Any 
feedback or comments?


On Tue, Jul 15, 2008 at 11:44 AM, Sainath Chowdary 
<[EMAIL PROTECTED] > wrote:


I very much agree with YunFeng that we should provide a mechanism to
link deployment plan and deployment descriptor. Even at present the
GEP deployment plan wizards are not able to get information from
deployment descriptor (like security roles, ejb-ref, resource-ref
etc) or when respective annotations are used in the source files.

I am currently working on the issue of having GEP Deployment Plan
get the necessary information from web.xml or annotations. I believe
that once we are able to retrieve necessary information from
deployment desciptor, we can easily extend the approach to add also.



On Tue, Jul 15, 2008 at 8:52 AM, YunFeng Ma <[EMAIL PROTECTED]
> wrote:

Now the GEP provides rich funnctionalities to edit geronimo
deployment plan, such as geronimo-web.xml, but it doesn't link
deployment plan and deployment descriptor. For example, adding a
EJB reference in the geronimo-web.xml Deployment editor only
changes deployment plan,  it doesn't add a ejb-ref to deployment
descriptor web.xml, the developers have to add the ejb-ref to
web.xml manually.
There are other such kind of pairs:  openejb-jar.xml vs.
ejb-jar.xml, geronio-application.xml vs. application.xml,
geronimo-ra.xml vs. ra.xml etc. 
Most importantly, the design of GEP has not provided a mechanism

to support this feature. I think we should consider this now
rather than later when GEP becomes more complicated. What's your
thought?

Thanks
-- Yun Feng




-- 
Thanks,

Sainath Chowdary
B.Tech III yr, Spring Semester
Electronics & Communication Engg
Indian Institute of Technology Roorkee




--
Thanks,
Sainath Chowdary
B.Tech III yr, Spring Semester
Electronics & Communication Engg
Indian Institute of Technology Roorkee


--
Thanks,
Tim McConnell

[jira] Updated: (GERONIMO-4131) Problems with WebSphere MQ RA deployment

[Jarek Gawor (JIRA)]

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

Jarek Gawor updated GERONIMO-4131:
--

Attachment: (was: GERONIMO-4131.patch)

> Problems with WebSphere MQ RA deployment
> 
>
> Key: GERONIMO-4131
> URL: https://issues.apache.org/jira/browse/GERONIMO-4131
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: connector
>Affects Versions: 2.0.1, 2.0.2, 2.1, 2.1.1, 2.1.2
>Reporter: Kevan Miller
>Assignee: Jarek Gawor
> Fix For: 2.1.2
>
> Attachments: GERONIMO-4131.patch
>
>
> A user reported problems deploying an MQ RA on Geronimo. Looks like there are 
> several problems.
> 1) we don't like config-property-name values in ra.xml to start with a lower 
> case letter
> 2) our mechanism for introspecting the implementation classes (e.g. 
> managedconnectionfactory-class) is not working properly. there can be 
> multiple "set" methods taking different parameter types. This is leading to 
> type-mismatches as we try to set attributes.

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

[jira] Updated: (GERONIMO-4131) Problems with WebSphere MQ RA deployment

[Jarek Gawor (JIRA)]

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

Jarek Gawor updated GERONIMO-4131:
--

Attachment: GERONIMO-4131.patch

Updated the patch to handle the port property (the port property has two 
setters setPort(int) and sertPort(String) so updated the code to also lookup 
the setters using the corresponding primitive type (if any)).


> Problems with WebSphere MQ RA deployment
> 
>
> Key: GERONIMO-4131
> URL: https://issues.apache.org/jira/browse/GERONIMO-4131
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: connector
>Affects Versions: 2.0.1, 2.0.2, 2.1, 2.1.1, 2.1.2
>Reporter: Kevan Miller
>Assignee: Jarek Gawor
> Fix For: 2.1.2
>
> Attachments: GERONIMO-4131.patch, GERONIMO-4131.patch
>
>
> A user reported problems deploying an MQ RA on Geronimo. Looks like there are 
> several problems.
> 1) we don't like config-property-name values in ra.xml to start with a lower 
> case letter
> 2) our mechanism for introspecting the implementation classes (e.g. 
> managedconnectionfactory-class) is not working properly. there can be 
> multiple "set" methods taking different parameter types. This is leading to 
> type-mismatches as we try to set attributes.

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

[jira] Assigned: (GERONIMO-4082) ignored for certain classes that are loaded by system class loader

[Kevan Miller (JIRA)]

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

Kevan Miller reassigned GERONIMO-4082:
--

Assignee: Kevan Miller

>  ignored for certain classes that are loaded by system class 
> loader
> ---
>
> Key: GERONIMO-4082
> URL: https://issues.apache.org/jira/browse/GERONIMO-4082
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: kernel
>Affects Versions: 2.1.1
> Environment: All
>Reporter: Manu T George
>Assignee: Kevan Miller
> Fix For: 2.1.2, 2.2
>
>
>  There is a problem with the hidden-classes element not
> working for asm classes. The reason was the optimized class loading
> mechanism which does not check if the classes are hidden before the
> code block given below
>   //
>// No dice, let's offer the primordial loader a shot...
>//
>try {
>return resolveClass(findSystemClass(name), resolve);
>} catch (ClassNotFoundException cnfe) {
>// ignore...just being a good citizen.
>}
> I was able to get this to work by reverting to the safe method of
> finding classes via the system property
> -DXorg.apache.geronimo.kernel.config.MPCLSearchOption=safe

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

Re: GEP should link deployment plan and deployment descriptor

[Sainath Chowdary]

Hi,

I completed the part of obtaining metadata complete information from
Deployment Descriptors of Web Projects. I have attached a patch to the
following JIRA for the same.
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-441

The new deployment descriptor classes are designed in such a way that it can
be easily extended for other types of deployment descriptors.
"AbstractDeploymentDescriptor" which is the parent for all other types
stores the metadata complete descriptor as "Object" type.
As J2EE and JavaEE webapp's are two totally complete unrelated classes
(atleast according to eclipse jst implementation), I created a interface in
our case "WebDeploymentDescriptor" which will be implemented by both J2EE
and JavaEE descriptor. So,Our future classes for EJBs can extend
AbstractDeploymentDescriptor and implement a EjbDeploymentDescriptor which
would be common for both J2EE and JavaEE EJB types.

Also a utility class is created which returns the abstract deployment
descriptor object properly initialized based on the type of project. Any
feedback or comments?

On Tue, Jul 15, 2008 at 11:44 AM, Sainath Chowdary <[EMAIL PROTECTED]>
wrote:

> I very much agree with YunFeng that we should provide a mechanism to link
> deployment plan and deployment descriptor. Even at present the GEP
> deployment plan wizards are not able to get information from deployment
> descriptor (like security roles, ejb-ref, resource-ref etc) or when
> respective annotations are used in the source files.
>
> I am currently working on the issue of having GEP Deployment Plan get the
> necessary information from web.xml or annotations. I believe that once we
> are able to retrieve necessary information from deployment desciptor, we can
> easily extend the approach to add also.
>
>
>
> On Tue, Jul 15, 2008 at 8:52 AM, YunFeng Ma <[EMAIL PROTECTED]> wrote:
>
>> Now the GEP provides rich funnctionalities to edit geronimo deployment
>> plan, such as geronimo-web.xml, but it doesn't link deployment plan and
>> deployment descriptor. For example, adding a EJB reference in the
>> geronimo-web.xml Deployment editor only changes deployment plan,  it doesn't
>> add a ejb-ref to deployment descriptor web.xml, the developers have to add
>> the ejb-ref to web.xml manually.
>> There are other such kind of pairs:  openejb-jar.xml vs. ejb-jar.xml,
>> geronio-application.xml vs. application.xml, geronimo-ra.xml vs. ra.xml
>> etc.
>> Most importantly, the design of GEP has not provided a mechanism to
>> support this feature. I think we should consider this now rather than later
>> when GEP becomes more complicated. What's your thought?
>>
>> Thanks
>> -- Yun Feng
>>
>>
>
>
> --
> Thanks,
> Sainath Chowdary
> B.Tech III yr, Spring Semester
> Electronics & Communication Engg
> Indian Institute of Technology Roorkee
>



-- 
Thanks,
Sainath Chowdary
B.Tech III yr, Spring Semester
Electronics & Communication Engg
Indian Institute of Technology Roorkee

Re: Download and Install in Geronimo Eclipse Plugin

[Ashish Jain]

Hi Ted,
Thanks for your comments! Yes the license does not pop up now. I had a look
at one of the tutorial on eclipse.org
http://www.eclipse.org/articles/Article-Update/keeping-up-to-date.html which
is on creating a update site. Just wondering if this can somehow fit in
GERONIMODEVTOOLS-416 not sure though.
Regarding creating a feature I am still looking into and will post my
findings soon onto JIRA. Let us have more discussion on 2) and move on
accordingly.

Thanks
Ashish

On Tue, Jul 15, 2008 at 8:17 PM, Ted Kirby <[EMAIL PROTECTED]> wrote:

> On Tue, Jul 15, 2008 at 7:07 AM, Ashish Jain <[EMAIL PROTECTED]> wrote:
> > Hi All!
> > I would like to work on the Download and Install in GEP. Currently I do
> not
> > find it intuitive and seems confusing. There are some issues with it
> which
> > are as follows
> >
> > 1) Before Selecting "Download and Install" we need to mention a directory
> > else the Download and Install Button will not be enabled. In this case we
> > need to manually create a directory.
>
> Yes, this screen and button are not the most intuitive.  But, it does
> provide good function.  There is a browse button next to the
> application server installation directory text box.  In the browse
> button dialog, there is a button/facility to create a new directory.
>
> > 2) Download and Install always installs the latest version of 2.x.x
> branch.
> > Currently by default 2.1.2 is downloaded. In case we want to download 2.1
> or
> > 2.1.1 that does not seems to be working.
>
> An interesting idea.  Note also GERONIMODEVTOOLS-416 "Add
> click-through license screen to Download and Install path" which
> should come first and be factored in, here particularly.  in
> addInstallableRuntimeSection in GeronimoRuntimeWizardFragment,
> installable.getLicense(monitor) can be used to get the license from a
> feature.  Note I recently defined v20 and v21 features.  See
> GERONIMODEVTOOLS-417 "Create a separate installable runtime feature
> for each version and type of geronimo server".  Were you going to
> create a feature for each, or roll your own code?  If the latter, then
> getLicense would probably not help here.




>
>
> > 3) Sizes of the various modules being installed are manually set
> currently.
> > Probably we can automate it. There is a JIRA also open for it
> > GERONIMODEVTOOLS-403.
>
> I think automation would be great!
>
> > Regarding this we can modify the Download and Install menu as follows
> >  Enable the button without entering the "Installation Directory". Once
> > "Download and Install" is selected it should pop up another menu showing
> the
> > different servers available for a particular version. Suppose We select
> > Apache geronimo Server V2.1 it should enlist 2.1, 2.1.1,
> 2.1.2(identifying
> > 2.1.2 as an unstable release since it is yet not released). Also in the
> same
> > window we can have specify the installation directory path to install the
> > server. If the directory is not present GEP will automatically create the
> > directory. Select Ok to start installation.
>
> The current code tells you if the directory exists or not.  It seems
> that some feedback or confirmation is desirable as opposed to blindly
> creating a non-existent directory.
>
> > If there are no concerns, I would like to go ahead and implement the
> above
> > features, and attach patches. Please suggest.
>
> As noted before, be sure to consider GERONIMODEVTOOLS-416.
>
> 3) has two JIRAs: 403 and 420.  It seems like 2) could be a new JIRA.
> Anything for 1) seems a fallout of 2).  I'd like to see some
> discussion of these issues before creating the new JIRA.
>
> Ted
>
> > Thanks
> > Ashish
> >
> >
>

[BUILD] branches/2.1: Failed for Revision: 677247

[gawor]

Geronimo Revision: 677247 built with tests included
 
See the full build-0800.log file at 
http://people.apache.org/builds/geronimo/server/binaries/2.1/20080716/build-0800.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/2.1/20080716
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 32 minutes 34 seconds
[INFO] Finished at: Wed Jul 16 08:45:48 EDT 2008
[INFO] Final Memory: 310M/1013M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
See detailed results at 
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
 
Assembly: tomcat
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/2.1/20080716/logs-0800-tomcat/test.log
 
 
Assembly: jetty
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/2.1/20080716/logs-0800-jetty/test.log
 
[INFO] Running console-testsuite.advance-test
[INFO] Tests run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 77.74 
sec <<< FAILURE!
 
Samples: branches/2.1
=
Log: 
http://people.apache.org/builds/geronimo/server/binaries/2.1/20080716/samples-0800.log
 
Build status: FAILED
 

Re: Fixing usability/accessibility issues in Admin Console

[Jack]

Thanks Keven for your comments!

A good start point on accessibility is here [1]. W3C has released a
guideline years ago [2]. And a newer version is under development (for a
long time) [3].

I understand that might be lengthy. So I extracted the most relavent
guidelines to Geronimo below. I suggest we can put it somewhere in our
developer's documentation. Can someone help to do that? Or can someone grant
me wrtie access to the confluence wiki? My account is caijunj.

As to the tools that we used to check accessibility, one is WebKing, and the
other is JAWS, both commercial software.
 - WebKing can scan the source code and detect accessibility issues based on
static code analysis.
 - JAWS is a popular screen reader software that people with visual problems
use to access information on a computer screen. It basically reads all the
information it understands via text-to-speech.

To make the mail not too lengthy, I'll discuss the error response formats in
another mail later on.

[1] http://www.w3.org/WAI/
[2] http://www.w3.org/TR/WCAG10/
[3] http://www.w3.org/TR/WCAG20/

*Web accessibility guidelines (short version)*
1. Provide equivalent alternatives to auditory and visual content.
 - Set meaningful ALT attribute for IMG, APPLET elements.
 - Provide equivalent text links if a server-side image map is used.

2. Don't rely on color alone.
 - Ensure that all information conveyed with color is also available without
color.

3. Use markup and style sheets and do so properly.
 - Use style sheets to control layout and presentation.
 - Use relative rather than absolute units in markup language attribute
values and style sheet property values. e.g., in CSS, use 'em' or percentage
lengths rather than 'pt' or 'cm'.

4. Create tables that transform gracefully.
 - For data tables, identify row and column headers. e.g., use TD to
identify data cells and TH to identify headers.
 - Do not use tables for layout unless the table makes sense when
linearized. Use css instead.

5. Ensure that pages featuring new technologies transform gracefully.
 - Ensure that pages are usable when scripts, applets, or other programmatic
objects are turned off or not supported. If this is not possible, provide
equivalent information on an alternative accessible page.

6. Provide context and orientation information.
 - Title each frame to facilitate frame identification and navigation. e.g.,
in HTML use the "title" attribute on FRAME elements.
 - Associate labels explicitly with their controls. e.g., in HTML use LABEL
and its "for" attribute.

7. Make all functionality operable through a keyboard interface.

8. Help users avoid mistakes and make it easy to correct mistakes that do
occur.

Jack


2008/7/5 Kevan Miller <[EMAIL PROTECTED]>:

>
> Hi Jack,
> Thanks for the information.
>
> I doubt that accessibility was given much (if any) thought during
> development of the console. We'll probably need some education about
> important factors regarding accessibility. If you have some pointers, they'd
> be welcome. Also, it looks like some tools have been used to identify
> problems with the console. It would be useful to understand what these tools
> are.
>
> From your description above, I think we'd welcome your contributions.
>
> Regarding 1), sounds like a reasonable approach. I think a specific
> illustration of your proposal would be useful.
>
> --kevan
>
>

[jira] Updated: (GERONIMODEVTOOLS-441) Retrieving Metadata complete Deployment Descriptor for Web Projects

[Sainath Chowdary (JIRA)]

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

Sainath Chowdary updated GERONIMODEVTOOLS-441:
--

  Assignee: Tim McConnell  (was: Sainath Chowdary)
Patch Info: [Patch Available]

> Retrieving Metadata complete Deployment Descriptor for Web Projects
> ---
>
> Key: GERONIMODEVTOOLS-441
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-441
> Project: Geronimo-Devtools
>  Issue Type: Sub-task
>  Components: eclipse-plugin
>Affects Versions: 2.1.2, 2.1.x
>Reporter: Sainath Chowdary
>Assignee: Tim McConnell
> Fix For: 2.1.2, 2.1.x
>
> Attachments: DeploymentDescriptor.patch
>
>
> Another critical aspect for porting plan creator work in GEP is to retrieve 
> the metadata complete deployment descriptor. This also links the deployment 
> descriptor and deployment plan effectively.
> This should emphasize at creating an architecture so that it can be easily 
> extended for other type of projects like EJBs, EARs etc. 

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

[jira] Assigned: (GERONIMODEVTOOLS-441) Retrieving Metadata complete Deployment Descriptor for Web Projects

[Sainath Chowdary (JIRA)]

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

Sainath Chowdary reassigned GERONIMODEVTOOLS-441:
-

Assignee: (was: Tim McConnell)

> Retrieving Metadata complete Deployment Descriptor for Web Projects
> ---
>
> Key: GERONIMODEVTOOLS-441
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-441
> Project: Geronimo-Devtools
>  Issue Type: Sub-task
>  Components: eclipse-plugin
>Affects Versions: 2.1.2, 2.1.x
>Reporter: Sainath Chowdary
> Fix For: 2.1.2, 2.1.x
>
> Attachments: DeploymentDescriptor.patch
>
>
> Another critical aspect for porting plan creator work in GEP is to retrieve 
> the metadata complete deployment descriptor. This also links the deployment 
> descriptor and deployment plan effectively.
> This should emphasize at creating an architecture so that it can be easily 
> extended for other type of projects like EJBs, EARs etc. 

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

[jira] Updated: (GERONIMODEVTOOLS-441) Retrieving Metadata complete Deployment Descriptor for Web Projects

[Sainath Chowdary (JIRA)]

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

Sainath Chowdary updated GERONIMODEVTOOLS-441:
--

Attachment: DeploymentDescriptor.patch

This patch allows GEP to obtain metadata complete information from Deployment 
Descriptor in Web Projects.

Although this patch only adds the functionality for Web Projects only, the 
architecture is in a way that it can be easily extended for EJBs, EARs etc. 
Also an util class is created which returns the AbstractDeploymentDescriptor 
(parent for all Deployment Desscriptors) object properly initialized according 
to its type.

> Retrieving Metadata complete Deployment Descriptor for Web Projects
> ---
>
> Key: GERONIMODEVTOOLS-441
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-441
> Project: Geronimo-Devtools
>  Issue Type: Sub-task
>  Components: eclipse-plugin
>Affects Versions: 2.1.2, 2.1.x
>Reporter: Sainath Chowdary
>Assignee: Sainath Chowdary
> Fix For: 2.1.2, 2.1.x
>
> Attachments: DeploymentDescriptor.patch
>
>
> Another critical aspect for porting plan creator work in GEP is to retrieve 
> the metadata complete deployment descriptor. This also links the deployment 
> descriptor and deployment plan effectively.
> This should emphasize at creating an architecture so that it can be easily 
> extended for other type of projects like EJBs, EARs etc. 

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

[jira] Commented: (GERONIMODEVTOOLS-275) Eclipse does not allow to download Apache Geronimo

[Ted Kirby (JIRA)]

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

Ted Kirby commented on GERONIMODEVTOOLS-275:


The current design is that GEP 2.1.2, the target for trunk, will run the G 
2.1.2 server.  You can change things how you want for your own purposes, but I 
think the existing code is properly configured.  Here is the entry in site .xml 
for tomcat:



There is a similar one for jetty.  

You have described how "Download and Install" works currently.
  


> Eclipse does not allow to download  Apache Geronimo
> ---
>
> Key: GERONIMODEVTOOLS-275
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-275
> Project: Geronimo-Devtools
>  Issue Type: Bug
>  Components: eclipse-plugin
>Affects Versions: 2.0.0
> Environment: Windows XP, GEP 2.0, WTP 201 all in one
>Reporter: Ashish Jain
>Assignee: Ashish Jain
> Fix For: 2.1.2
>
>
> I have WTP 201 all in one with Eclipse plugin installed over it. While trying 
> to add a new server, Eclipse prompts to download and install the server. 
> While trying to do this I am not able to select DOWNLOAD and INSTALL Option. 
> It seems that eclipse has hanged but guess the check boxes and the Buttons 
> are not enabled.

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

Re: Geronimo trunk build failure with fresh OpenEjb trunk build

[Rick McGuire]

David Blevins wrote:


On Jul 15, 2008, at 10:55 AM, Rick McGuire wrote:

I just committed this change.  It doesn't look like this is causing 
any tck issues.


Guessing a lot of those places you added the 3.1 api were more or less 
"just in case".  You definitely shouldn't need it in any modules that 
don't directly use the new ejb 3.1 API (thinking of the test suite and 
mejb).
Unfortunately, not true.  Any code that used the annotation deployer 
either directly or indirectly got the same error.  mejb, in fact, was 
the first place that got hit after I applied the two changes you 
recommended.  The direct references to the Singleton class were causing 
the issue.  After fixing mejb, it started to turn into a game of 
"whack-a-mole", so ended up doing a blanket add wherever the ejb 3.0 
specs were used.


Rick


-David


Joe Bohn wrote:


Rick McGuire wrote:

David Blevins wrote:


On Jul 10, 2008, at 1:17 PM, Joe Bohn wrote:

If I build Geronimo trunk using the latest OpenEjb snapshots 
(published around 6/27-28) things build fine.  However, if I grab 
OpenEjb trunk and build it locally (to get the latest image) I 
get build failures (NoClassDefFoundError) in the Geronimo MEJB 
config.  I suspect we need to make some changes to accommodate 
the Singleton Session Beans implementation.  Is this complete yet 
and is anybody looking into the necessary Geronimo changes?


We'd need to get this dep in the right place if we wanted to keep 
using OpenEJB trunk:


   
 org.apache.openejb
 ejb31-api-experimental
 ${openejbVersion}
   

These two poms seem to be the only places where the ejb 3.0 spec 
jar is used:


./framework/configs/jee-specs/pom.xml
./framework/modules/geronimo-j2ee/pom.xml

I'm fine giving it a shot if no one objects to being dependent on 
a non-final spec jar.  We might try it out and see if the tck 
complains at least.
I needed to do this to get a clean build using the latest, and it's 
a lot more than just those two poms that needed updating.  I'm 
going to try doing some tck runs to see how things look.


Rick



Hi Rick,  Is this at a point where you can check it in?  Everybody 
is hitting the trunk build break now that new openejb snapshots have 
been published.


Thanks,
Joe








-David

--- 


[INFO] Building Geronimo Plugins, MEJB :: Config
[INFO]task-segment: [install]
[INFO] 
 


[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:validate-configuration]
[INFO] [car:prepare-plan]
[INFO] Generated: 
/home/jbohn/geronimo/plugins/mejb/mejb/target/resources/META-INF/plan.xml 


[INFO] [car:package]
[INFO] Packaging module configuration: 
/home/jbohn/geronimo/plugins/mejb/mejb/target/resources/META-INF/plan.xml 

[INFO] Started deployer: 
org.apache.geronimo.framework/geronimo-gbean-deployer/2.2-SNAPSHOT/car 

[INFO] Started deployer: 
org.apache.geronimo.configs/openejb-deployer/2.2-SNAPSHOT/car
14:13:36,387 INFO  [config] Configuring Service(id=Default 
Stateless Container, type=Container, provider-id=Default 
Stateless Cont

ainer)
14:13:36,392 INFO  [config] Configuring Service(id=Default 
Stateful Container, type=Container, provider-id=Default Stateful 
Contai

ner)
14:13:36,393 INFO  [config] Configuring Service(id=Default BMP 
Container, type=Container, provider-id=Default BMP Container)
14:13:36,394 INFO  [config] Configuring Service(id=Default CMP 
Container, type=Container, provider-id=Default CMP Container)
14:13:36,402 INFO  [config] Configuring enterprise application: 
org.apache.geronimo.configs/mejb/2.2-SNAPSHOT/car

[ERROR] Deployment failed due to
java.lang.NoClassDefFoundError: javax/ejb/Singleton
org.apache.openejb.config.AnnotationDeployer$DiscoverAnnotatedBeans.deploy(AnnotationDeployer.java:339) 

org.apache.openejb.config.AnnotationDeployer$DiscoverAnnotatedBeans.deploy(AnnotationDeployer.java:230) 

org.apache.openejb.config.AnnotationDeployer.deploy(AnnotationDeployer.java:174) 

org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:228) 

org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:584) 

org.apache.geronimo.openejb.deployment.EjbModuleBuilder.configureApplication(EjbModuleBuilder.java:645) 

[jira] Created: (GERONIMODEVTOOLS-441) Retrieving Metadata complete Deployment Descriptor for Web Projects

[Sainath Chowdary (JIRA)]

Retrieving Metadata complete Deployment Descriptor for Web Projects
---

 Key: GERONIMODEVTOOLS-441
 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-441
 Project: Geronimo-Devtools
  Issue Type: Sub-task
  Components: eclipse-plugin
Affects Versions: 2.1.2, 2.1.x
Reporter: Sainath Chowdary
Assignee: Sainath Chowdary
 Fix For: 2.1.2, 2.1.x


Another critical aspect for porting plan creator work in GEP is to retrieve the 
metadata complete deployment descriptor. This also links the deployment 
descriptor and deployment plan effectively.

This should emphasize at creating an architecture so that it can be easily 
extended for other type of projects like EJBs, EARs etc. 

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

[jira] Commented: (GERONIMODEVTOOLS-340) GEP editor error opening Geronimo deployment plan(s) with 1.1 namespaces

[YunFeng Ma (JIRA)]

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

YunFeng Ma commented on GERONIMODEVTOOLS-340:
-

The above sample deployment plan can be opened after applying the patch in 
GERONIMODEVTOOLS-440.

> GEP editor error opening Geronimo deployment plan(s) with 1.1 namespaces
> 
>
> Key: GERONIMODEVTOOLS-340
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-340
> Project: Geronimo-Devtools
>  Issue Type: Bug
>  Components: eclipse-plugin
>Affects Versions: 2.1.0
>Reporter: Tim McConnell
>Assignee: Tim McConnell
> Fix For: 2.1.2
>
>
> For example:
> 
> http://geronimo.apache.org/xml/ns/j2ee/web-1.1";
> xmlns:nam="http://geronimo.apache.org/xml/ns/naming-1.1";
> xmlns:sec="http://geronimo.apache.org/xml/ns/security-1.1";
> xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.1";>
> 
> 
> default
> WebJDBC
> 1.0
> car
> 
> 
> 
> console.dbpool
> jdbc%2Fuserds
> 
> 
> 
> /WebJDBC
> 
> jdbc/userds
> 
> console.dbpool
> jdbc%2Fuserds
> jdbc/userds
> 
> 
> 

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

[jira] Updated: (GERONIMODEVTOOLS-440) Convert the old deployment plan to the current version using NamespaceFilter

[YunFeng Ma (JIRA)]

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

YunFeng Ma updated GERONIMODEVTOOLS-440:


Attachment: GERONIMODEVTOOLS-440.patch

We've had a method unmarshalFilterDeploymentPlan( IFile file ) in JAXBUtils 
which use NamespaceFilter to convert the old deployment plan to the current 
version. I think we should always use this method to unmarshal the deployment 
plan, instead of  method unmarshalDeploymentPlan(IFile file). 

This patch removed method unmarshalDeploymentPlan(IFile file) and changed the 
codes which invoke unmarshalDeploymentPlan(IFile file) to 
unmarshalFilterDeploymentPlan( IFile file ).

> Convert the old deployment plan to the current version using NamespaceFilter
> 
>
> Key: GERONIMODEVTOOLS-440
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-440
> Project: Geronimo-Devtools
>  Issue Type: Bug
>  Components: eclipse-plugin
>Affects Versions: 2.1.x
>Reporter: YunFeng Ma
>Assignee: Tim McConnell
> Attachments: GERONIMODEVTOOLS-440.patch
>
>
> GEP can not open the following old deployment plan:
> {noformat}
> http://www.openejb.org/xml/ns/openejb-jar-2.1"; 
>  xmlns:nam="http://geronimo.apache.org/xml/ns/naming-1.2"; 
>  xmlns:sec="http://geronimo.apache.org/xml/ns/security-1.2"; 
>  xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.2";>
>  
>   
> 
>   samples
>   MDBDemo
>   2.1
>   car
> 
> 
>   
> org.apache.geronimo.configs
> activemq-ra
> car
>   
> 
> 
> 
>   
>   
>   
> 
>   SampleMDB
>   
> ActiveMQ RA
>   
>   
> 
>   
> destination
>   
> SendReceiveQueue
> 
> 
>   
> destinationType
>   
> javax.jms.Queue
> 
>   
>   
> CustomerHomeRemote
> CustomerEJB
>   
> 
> 
> 
>   CustomerEJB
>   CustomerHomeRemote
>   
>   
> jdbc/ibm-demo
> SystemDatasource
>   
> 
>   
> 
> {noformat}

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

[jira] Created: (GERONIMODEVTOOLS-440) Convert the old deployment plan to the current version using NamespaceFilter

[YunFeng Ma (JIRA)]

Convert the old deployment plan to the current version using NamespaceFilter


 Key: GERONIMODEVTOOLS-440
 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-440
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 2.1.x
Reporter: YunFeng Ma
Assignee: Tim McConnell


GEP can not open the following old deployment plan:
{noformat}
http://www.openejb.org/xml/ns/openejb-jar-2.1"; 
 xmlns:nam="http://geronimo.apache.org/xml/ns/naming-1.2"; 
 xmlns:sec="http://geronimo.apache.org/xml/ns/security-1.2"; 
 xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.2";>
 
  

  samples
  MDBDemo
  2.1
  car


  
org.apache.geronimo.configs
activemq-ra
car
  



  
  
  

  SampleMDB
  
ActiveMQ RA
  
  

  
destination
  
SendReceiveQueue


  
destinationType
  
javax.jms.Queue

  
  
CustomerHomeRemote
CustomerEJB
  



  CustomerEJB
  CustomerHomeRemote
  
  
jdbc/ibm-demo
SystemDatasource
  

  



{noformat}

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

Re: svn commit: r675220 - in /geronimo/server/trunk/plugins: console/console-core/src/main/java/org/apache/geronimo/console/util/ plancreator/plancreator-portlets/src/main/java/org/apache/geronimo/con

[Shiva Kumar H R]

I had earlier replied to Kevan's mail. Looks like some problem with my
mailbox and it didn't get through. I will be reverting these changes and
committing Sainath's patch today.

And thanks very much Sainath for your awesome work on GERONIMODEVTOOLS-434.

On Wed, Jul 16, 2008 at 11:53 AM, Sainath Chowdary <[EMAIL PROTECTED]>
wrote:

> Hi Kevan,
>
> Now we can pretty much delete the servlet added to plan creator for
> providing dynamic information to GEP. The following JIRA solves the problem
> using JMX to query the server directly.
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-434
>
>
> On Tue, Jul 15, 2008 at 11:03 PM, Kevan Miller <[EMAIL PROTECTED]>
> wrote:
>
>>
>> On Jul 9, 2008, at 12:00 PM, Shiva Kumar H R wrote:
>>
>>  Thanks Jarek, I will explore JMX to see if I can get all the dynamic info
>>> I am looking for. If JMX does provide such info, I will revert back all
>>> these and use JMX instead.
>>>
>>
>> Shiva,
>> How do things stand with your investigations? IMO, this change is not
>> appropriate.
>>
>> --kevan
>>
>>
>
>
> --
> Thanks,
> Sainath Chowdary
> B.Tech III yr, Spring Semester
> Electronics & Communication Engg
> Indian Institute of Technology Roorkee
>



-- 
Thanks,
Shiva