date:20070703


[ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509785
 ] 

Paul Grove commented on GERONIMODEVTOOLS-141:
-

Any news on this issue as this is holding up our companies adoption on Eclipse 
3.3 as we use Geronimo and would like to use the plug-in. I did note the 
offending plug-in com.ibm.etools.emf.event was packaged in Eclipses 3.2 but 
not in Eclipse 3.3.

 Installation/Activation of Plugin fails
 ---

 Key: GERONIMODEVTOOLS-141
 URL: 
 https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-141
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 1.2.0
 Environment: Windows XP SP2, Java 1.6.0_01, Eclipse 3.3 M6, WST 2.0 M6
Reporter: Stefan
Priority: Blocker

 Via Eclipse function to download additional server adapters you can choose 
 and install the plugin.
 But after restart Eclipse the plugin is disabled. If you try to enable it, 
 you get:
 Requested operation cannot be performed because it would invalidate the 
 current configuration. See details for more information. 
 org.apache.geronimo.feature (1.2.0) requires plug-in 
 com.ibm.etools.emf.event.

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

[jira] Commented: (GERONIMODEVTOOLS-141) Installation/Activation of Plugin fails

2007-07-03 Thread Jacek Laskowski (JIRA)

[
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509792
]

Jacek Laskowski commented on GERONIMODEVTOOLS-141:
--

I'm using the latest Geronimo plugin release with Eclipse IDE 3.3 just fine -
download one from http://people.apache.org/dist/geronimo/eclipse/unstable/
(building now the very latest version). It seems that the official distribution
of the plugin isn't updated and is slightly error-prone. Could you verify that
the unstable version works before we push the latest binaries to the official
repos? (I don't know what's needed so don't ask me...very politely...why I
haven't done that yet ;-))

Installation/Activation of Plugin fails
---

Key: GERONIMODEVTOOLS-141
URL:
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-141
Project: Geronimo-Devtools
Issue Type: Bug
Components: eclipse-plugin
Affects Versions: 1.2.0
Environment: Windows XP SP2, Java 1.6.0_01, Eclipse 3.3 M6, WST 2.0 M6
Reporter: Stefan
Priority: Blocker

Via Eclipse function to download additional server adapters you can choose
and install the plugin.
But after restart Eclipse the plugin is disabled. If you try to enable it,
you get:
Requested operation cannot be performed because it would invalidate the
current configuration. See details for more information.
org.apache.geronimo.feature (1.2.0) requires plug-in
com.ibm.etools.emf.event.

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

[jira] Commented: (GERONIMODEVTOOLS-141) Installation/Activation of Plugin fails

2007-07-03 Thread Erik-Berndt Scheper (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509805
 ] 

Erik-Berndt Scheper commented on GERONIMODEVTOOLS-141:
--

OK, please help me how to update to this unstable plugin -- better an unstable 
plugin than one that disables Eclipse update functionality.

 Installation/Activation of Plugin fails
 ---

 Key: GERONIMODEVTOOLS-141
 URL: 
 https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-141
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 1.2.0
 Environment: Windows XP SP2, Java 1.6.0_01, Eclipse 3.3 M6, WST 2.0 M6
Reporter: Stefan
Priority: Blocker

 Via Eclipse function to download additional server adapters you can choose 
 and install the plugin.
 But after restart Eclipse the plugin is disabled. If you try to enable it, 
 you get:
 Requested operation cannot be performed because it would invalidate the 
 current configuration. See details for more information. 
 org.apache.geronimo.feature (1.2.0) requires plug-in 
 com.ibm.etools.emf.event.

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

[jira] Commented: (GERONIMODEVTOOLS-141) Installation/Activation of Plugin fails


[ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509817
 ] 

Paul Grove commented on GERONIMODEVTOOLS-141:
-

Jacek,
I have deployed the unstable plug-in to my Eclipse Europa build and have 
managed to Start - Stop the server and deploy a basic war. So it looks good to 
me. Thanks for the help. So whats next, how does this get rolled out so that 
the Eclipse update site works with Eclipse 3.3? Must admiit this is my first 
time using Jira. :-0 

 Installation/Activation of Plugin fails
 ---

 Key: GERONIMODEVTOOLS-141
 URL: 
 https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-141
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 1.2.0
 Environment: Windows XP SP2, Java 1.6.0_01, Eclipse 3.3 M6, WST 2.0 M6
Reporter: Stefan
Priority: Blocker

 Via Eclipse function to download additional server adapters you can choose 
 and install the plugin.
 But after restart Eclipse the plugin is disabled. If you try to enable it, 
 you get:
 Requested operation cannot be performed because it would invalidate the 
 current configuration. See details for more information. 
 org.apache.geronimo.feature (1.2.0) requires plug-in 
 com.ibm.etools.emf.event.

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

[jira] Commented: (GERONIMODEVTOOLS-141) Installation/Activation of Plugin fails

2007-07-03 Thread Jacek Laskowski (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509820
 ] 

Jacek Laskowski commented on GERONIMODEVTOOLS-141:
--

I don't know about the process of publishing the plugin to the official Eclipse 
plugin repository. Would you mind upgrading your unstable plugin to the latest 
one - 
http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-2.0.0-v20070703.1201-deployable.zip
 and giving it a shot? I've just copied it over.

Good to hear you're having lots of fun! ;-)

 Installation/Activation of Plugin fails
 ---

 Key: GERONIMODEVTOOLS-141
 URL: 
 https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-141
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 1.2.0
 Environment: Windows XP SP2, Java 1.6.0_01, Eclipse 3.3 M6, WST 2.0 M6
Reporter: Stefan
Priority: Blocker

 Via Eclipse function to download additional server adapters you can choose 
 and install the plugin.
 But after restart Eclipse the plugin is disabled. If you try to enable it, 
 you get:
 Requested operation cannot be performed because it would invalidate the 
 current configuration. See details for more information. 
 org.apache.geronimo.feature (1.2.0) requires plug-in 
 com.ibm.etools.emf.event.

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

[jira] Commented: (GERONIMODEVTOOLS-141) Installation/Activation of Plugin fails


[ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509825
 ] 

Paul Grove commented on GERONIMODEVTOOLS-141:
-

Jacek,
I have tested this file 
http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-2.0.0-v20070703.1201-deployable.zip
 in terms of Start - Stop the server and deploy a basic war and all looks ok.


 Installation/Activation of Plugin fails
 ---

 Key: GERONIMODEVTOOLS-141
 URL: 
 https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-141
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 1.2.0
 Environment: Windows XP SP2, Java 1.6.0_01, Eclipse 3.3 M6, WST 2.0 M6
Reporter: Stefan
Priority: Blocker

 Via Eclipse function to download additional server adapters you can choose 
 and install the plugin.
 But after restart Eclipse the plugin is disabled. If you try to enable it, 
 you get:
 Requested operation cannot be performed because it would invalidate the 
 current configuration. See details for more information. 
 org.apache.geronimo.feature (1.2.0) requires plug-in 
 com.ibm.etools.emf.event.

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

Re: [DISCUSS] Geronimo 2.1 - what's next?

2007-07-03 Thread Shiva Kumar H R


I would be happy to see the work on Admin Console Portlet for Auto
Generating Geronimo Deployment Plan getting complete and shipped with AG
2.1. May be I am a bit too ambitious, but an ultimate test would be: portlet
auto generating the deployment plan for 'Daytrader' application ;-)

- Shiva

On 7/2/07, Matt Hogstrom [EMAIL PROTECTED] wrote:


Seems like the dev list has been  a bit quiet lately as I know many
folks have been working on getting 2.0 done and through some
additional testing for Axis, fit and finish stuff, etc.  Although
important, its not exactly the next generation so I thought I'd start
this thread to get some ideas formed around the next step for AG.
These are just my thoughts and I'm soliciting input for ideas and
discussion.

I thought I'd put my thoughts in the form of a user describing what
they need from Geronimo.  This is based on input I've heard from
several folks as well as users and includes some of my own ideas as
well.  It feels like we've been chasing the specs for so long that we
haven't fully realized some of the other awesome ideas people have
had.  Aaron's plugin architecture is workable but not fully
consumable, Dain's repository work and a host of other ideas.  I
think now is the time to have some fun.To that end here is the
list of requirements.

Geronimo 2.1 Punch List

*Flexible framework for building server assemblies that include only
the components needed for an application*

This means that a user could either build a custom assembly with only
the needed parts or, alternatively, could run with all parts
available but only start what they need.  The model is up to the user
to decide based on their unique requirements.

*Dynamically binding needed elements*

Using the plugin architecture and Maven repo concepts one could
install a needed element into the server by simply pointing to a
remote repository and installing the element.  Other artifacts needed
for execution would be obtained automagically from either the network
or a shared filesystem as needed and based on the policies provided
by the user.  The default mode of operation would provide the best
user experience.

*Dynamic Console for managing installed artifacts*

Improve the console framework to allow installed artifacts to
register a portlet for managing the configuration.  For highest level
of flexibility a component would provide the required portlet elemtns
and we would bind them into the navigation framework and security
infracstructure.  We'd need a good set of docs and samples to help
people in deploying this easy.  Ideally we would start with a minimal
assembly and a mgmt console so that new functions could be loaded
through the console.  I'm not sure that we'd need to have an assembly
smaller than minimal at this point since we'd need a web container
for the mgmt console anyway.

*Cluster Aware Mgmt Application*

For users that want to federate a number of servers together we need
a clustering solution that will allow for configuration of nodes as
well as autodiscovery.  This requires a clustering element for
Geronimo that takes into account multiple clustering users
(services).  I think Jeff has some of the foundation in GCache.


*SOA Assembly*
It would be great to have a SOA assembly (that works in a flexible
way :) with AMQ, ServiceMix and a Tx Manager.  A LOT of people I talk
to want something simple like a Tomcat and a Mule...let's give it to
them.


*Tooling*
A really huge part of what people have talked about as being
important is tooling integration (I've heard mostly about Eclipse and
NetBeans).


*OSGi and Spring*
This has been kicked around for a long time.  I was talking with
someone who said they needed a flexible runtime that would allow them
to wire in OSGi bundles (seems like the traction is increasing) and
use Spring for the configuration.  People smarter than I can weigh in
on this area but this is seems to get Independent Software Vendors
(ISV's) all hot under the collar.  If we could deliver this with the
flexible server stuff I think we'd have a huge swell of interest.


Other thoughts?

Re: [DISCUSS] Geronimo 2.1 - what's next?

2007-07-03 Thread Jason Dillon


+1

I'm all for more work on the console bits.

--jason


On Jul 3, 2007, at 4:07 AM, Shiva Kumar H R wrote:

I would be happy to see the work on Admin Console Portlet for Auto  
Generating Geronimo Deployment Plan getting complete and shipped  
with AG 2.1. May be I am a bit too ambitious, but an ultimate test  
would be: portlet auto generating the deployment plan for  
'Daytrader' application ;-)


- Shiva

On 7/2/07, Matt Hogstrom [EMAIL PROTECTED] wrote:
Seems like the dev list has been  a bit quiet lately as I know many
folks have been working on getting 2.0 done and through some
additional testing for Axis, fit and finish stuff, etc.  Although
important, its not exactly the next generation so I thought I'd start
this thread to get some ideas formed around the next step for AG.
These are just my thoughts and I'm soliciting input for ideas and
discussion.

I thought I'd put my thoughts in the form of a user describing what
they need from Geronimo.  This is based on input I've heard from
several folks as well as users and includes some of my own ideas as
well.  It feels like we've been chasing the specs for so long that we
haven't fully realized some of the other awesome ideas people have
had.  Aaron's plugin architecture is workable but not fully
consumable, Dain's repository work and a host of other ideas.  I
think now is the time to have some fun.To that end here is the
list of requirements.

Geronimo 2.1 Punch List

*Flexible framework for building server assemblies that include only
the components needed for an application*

This means that a user could either build a custom assembly with only
the needed parts or, alternatively, could run with all parts
available but only start what they need.  The model is up to the user
to decide based on their unique requirements.

*Dynamically binding needed elements*

Using the plugin architecture and Maven repo concepts one could
install a needed element into the server by simply pointing to a
remote repository and installing the element.  Other artifacts needed
for execution would be obtained automagically from either the network
or a shared filesystem as needed and based on the policies provided
by the user.  The default mode of operation would provide the best
user experience.

*Dynamic Console for managing installed artifacts*

Improve the console framework to allow installed artifacts to
register a portlet for managing the configuration.  For highest level
of flexibility a component would provide the required portlet elemtns
and we would bind them into the navigation framework and security
infracstructure.  We'd need a good set of docs and samples to help
people in deploying this easy.  Ideally we would start with a minimal
assembly and a mgmt console so that new functions could be loaded
through the console.  I'm not sure that we'd need to have an assembly
smaller than minimal at this point since we'd need a web container
for the mgmt console anyway.

*Cluster Aware Mgmt Application*

For users that want to federate a number of servers together we need
a clustering solution that will allow for configuration of nodes as
well as autodiscovery.  This requires a clustering element for
Geronimo that takes into account multiple clustering users
(services).  I think Jeff has some of the foundation in GCache.


*SOA Assembly*
It would be great to have a SOA assembly (that works in a flexible
way :) with AMQ, ServiceMix and a Tx Manager.  A LOT of people I talk
to want something simple like a Tomcat and a Mule...let's give it to
them.


*Tooling*
A really huge part of what people have talked about as being
important is tooling integration (I've heard mostly about Eclipse and
NetBeans).


*OSGi and Spring*
This has been kicked around for a long time.  I was talking with
someone who said they needed a flexible runtime that would allow them
to wire in OSGi bundles (seems like the traction is increasing) and
use Spring for the configuration.  People smarter than I can weigh in
on this area but this is seems to get Independent Software Vendors
(ISV's) all hot under the collar.  If we could deliver this with the
flexible server stuff I think we'd have a huge swell of interest.


Other thoughts?

[jira] Commented: (GERONIMODEVTOOLS-141) Installation/Activation of Plugin fails

2007-07-03 Thread Sachin Patel (JIRA)

[
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509838
]

Sachin Patel commented on GERONIMODEVTOOLS-141:
---

The eclipse plugin that is currently on the update site is for WTP 1.5.4 only.
There are issues with it installing it on Eclipse 3.3/WTP2.0. Since these are
released binaries they cannot be cracked open and modified to prevent
installation on Eclipse 3.3.

As far as the unstable driver that is supported on WTP2.0. It will be
published on the update site, once Geronimo 2.0 is released (in order to break
snapshot depenencies) and secondly, once the plugin has gone through the voting
process. You can expect RC drivers to roll out once Geronimo 2.0 is released.
In the meantime please continue to use the daily drivers and go through the
manual (non update mgr) installation process.

Installation/Activation of Plugin fails
---

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

[jira] Closed: (GERONIMODEVTOOLS-141) Installation/Activation of Plugin fails

2007-07-03 Thread Sachin Patel (JIRA)


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

Sachin Patel closed GERONIMODEVTOOLS-141.
-

Resolution: Won't Fix
  Assignee: Sachin Patel

 Installation/Activation of Plugin fails
 ---

 Key: GERONIMODEVTOOLS-141
 URL: 
 https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-141
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 1.2.0
 Environment: Windows XP SP2, Java 1.6.0_01, Eclipse 3.3 M6, WST 2.0 M6
Reporter: Stefan
Assignee: Sachin Patel
Priority: Blocker

 Via Eclipse function to download additional server adapters you can choose 
 and install the plugin.
 But after restart Eclipse the plugin is disabled. If you try to enable it, 
 you get:
 Requested operation cannot be performed because it would invalidate the 
 current configuration. See details for more information. 
 org.apache.geronimo.feature (1.2.0) requires plug-in 
 com.ibm.etools.emf.event.

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

[jira] Commented: (GERONIMO-3265) Spring stale version in 2.0-M6-rc1

2007-07-03 Thread Daniel Kulp (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509873
 ] 

Daniel Kulp commented on GERONIMO-3265:
---

CXF does use spring.   However, we pull in 2.0.4 (and work fine with 2.0.5).
I'm not sure where the 2.0 version would be coming from. 



 Spring stale version in 2.0-M6-rc1
 --

 Key: GERONIMO-3265
 URL: https://issues.apache.org/jira/browse/GERONIMO-3265
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
Affects Versions: 2.0-M6
 Environment: Windows XP SP2, Sun JSDK 1.5.07, Geronimo (2.0-M6-rc1) 
 obtained from:
 http://people.apache.org/~hogstrom/2.0-M6-rc1/geronimo-tomcat6-jee5-2.0-M6-rc1-bin.zip
  (2.0-M6-rc1)
Reporter: Alexei Kozich

 1. This Geronimo build includes spring-beans.jar, spring-context.jar and 
 spring-core.jar of version 2.0.
 So as far as we know, version 2.0 does not fully support integration with JPA 
 implementations.
 2. We developed an enterprise application (ear) which utilizes Spring 2.0.2 
 and OpenJPA.
 OpenJPA comes with Geronimo.
 Deployment and start of this application fails, because of different versions 
 of Spring (our application expects spring-beans.jar, spring-context.jar and 
 spring-core.jar to be at least of version 2.0.2 but Geronimo contains libs of 
 version 2.0 (the lack of some methods in version 2.0 is the problem here).
 3. If we try to use inverse-classloading or hidden classes 
 (org.springframework) in geronimo-web.xml and include all necesary libs in 
 WEB-INF/lib following Exception is thrown during deployment and start of the 
 application (see below).
 4. We found temporary workaround: to replace  spring-beans.jar, 
 spring-context.jar and spring-core.jar of version 2.0 with jars of version 
 2.0.2 in Geronimo repository without using of inverse-classloading and hidden 
 classes and everything looks fine.
 5. So as far as I understand this out-of-the-box Geronimo build could not be 
 used as Server for Spring-OpenJPA appications. At least  Spring libs upgrade 
 could solve this problem.
 6. Another problem is following Exception when using hidden classes or 
 inverse-classloading to load application jars first.
 ERROR [ContextLoader] Context initialization failed
 org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected 
 exception parsing XML document from ServletContext resource 
 [/WEB-INF/springAppContext.xml]; nested exception is 
 java.lang.IllegalArgumentException: Class 
 [org.apache.cxf.clustering.spring.NamespaceHandler] does not implement the 
 NamespaceHandler interface
 Caused by: 
 java.lang.IllegalArgumentException: Class 
 [org.apache.cxf.clustering.spring.NamespaceHandler] does not implement the 
 NamespaceHandler interface
   at 
 org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.initHandlerMappings(DefaultNamespaceHandlerResolver.java:119)
   at 
 org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.init(DefaultNamespaceHandlerResolver.java:96)
   at 
 org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.init(DefaultNamespaceHandlerResolver.java:82)
   at 
 org.springframework.beans.factory.xml.XmlBeanDefinitionReader.createDefaultNamespaceHandlerResolver(XmlBeanDefinitionReader.java:526)
   at 
 org.springframework.beans.factory.xml.XmlBeanDefinitionReader.createReaderContext(XmlBeanDefinitionReader.java:515)
   at 
 org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:495)
   at 
 org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)
   at 
 org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:340)
   at 
 org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:317)
   at 
 org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:125)
   at 
 org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:141)
   at 
 org.springframework.web.context.support.XmlWebApplicationContext.loadBeanDefinitions(XmlWebApplicationContext.java:123)
   at 
 org.springframework.web.context.support.XmlWebApplicationContext.loadBeanDefinitions(XmlWebApplicationContext.java:91)
   at 
 org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:94)
   at 
 org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:292)
   at

[jira] Created: (GERONIMO-3299) ejb 3.0 annotation converter for j2g

ejb 3.0 annotation converter for j2g


 Key: GERONIMO-3299
 URL: https://issues.apache.org/jira/browse/GERONIMO-3299
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public (Regular issues)
  Components: J2G
 Environment: windows xp
Reporter: Viet Hung Nguyen
 Attachments: AnnotationConverter.java

We need to be able to convert JBoss EJB annotations (which are sometimes 
supported by JBoss and not Geronimo) to what Geronimo supports.

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

[jira] Updated: (GERONIMO-3299) ejb 3.0 annotation converter for j2g


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

Viet Hung Nguyen updated GERONIMO-3299:
---

Attachment: AnnotationConverter.java

 ejb 3.0 annotation converter for j2g
 

 Key: GERONIMO-3299
 URL: https://issues.apache.org/jira/browse/GERONIMO-3299
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: J2G
 Environment: windows xp
Reporter: Viet Hung Nguyen
 Attachments: AnnotationConverter.java


 We need to be able to convert JBoss EJB annotations (which are sometimes 
 supported by JBoss and not Geronimo) to what Geronimo supports.

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

[jira] Updated: (GERONIMO-3299) ejb 3.0 annotation converter for j2g


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

Viet Hung Nguyen updated GERONIMO-3299:
---

Attachment: (was: AnnotationConverter.java)

 ejb 3.0 annotation converter for j2g
 

 Key: GERONIMO-3299
 URL: https://issues.apache.org/jira/browse/GERONIMO-3299
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: J2G
 Environment: windows xp
Reporter: Viet Hung Nguyen

 We need to be able to convert JBoss EJB annotations (which are sometimes 
 supported by JBoss and not Geronimo) to what Geronimo supports.

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

Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)

2007-07-03 Thread Manu George


Hi ,
   From Paul's mail I guess a Geronimo plugin would be
the way forward. I am going to list down a few more questions on the
scenarios that Sebastien has explained. The scenarios are given first
and then my understanding, approach and issues. I would be just
listing two of the scenarios and trying to implement them initially.

(a) I develop SCA components, assemble them in a composite, package them
in an SCA contribution. I don't really know what a WAR or an EAR is, I'm
just using the SCA programming model and packaging model. I deploy my
SCA contribution to Geronimo and run it there.

This will require a tuscany specific deployer that is installed as
part of the plugin. Ususally deployers have access to a server
specific deployment plan at some fixed path say
(META-INF/geronimo-tuscany.xml). If this file is found then the
deployer will know that the module that was supplied to it is a
tuscany module. In case I am deploying a tuscany contribution using
the sca packaging model then there will be a .composite file somewhere
in the module and the deployer will have to search in the module for
scdl files.  For now the tuscany  contributions will always be
packaged as jars.

This will mean that if the deployer finds this file then it will
handle the module as a tuscany module and if not found relinquish
control to other deployers.

Now we come to the question of the Domain. This has been a vexing
question for me. I think that going for a single SCADomain for the
entire server would be a good place to start.
All the applications will have an application composite and that
composite will be deployed on the server wide SCADomain. What the
server wide SCADomain should provide is the ability to add and remove
composites at runtime. If I am not mistaken this will be supported by
the EmbeddedSCADomain. Can someone in the know comment on this.

The other logical approach would be to go for different partial
SCADomain instances per contribution. These different instances will
still have information about the other instances and will do the
wiring across the instances that constitute a complete SCADomain.
From what I could find, this type of an SCADomain is not
supported currently. There is work on an SCADomain spanning multiple
runtimes. This would be a simpler case of an SCADomain spanning
multiple classloaders or (configurations in Geronimo).

The reason for not going with the second approach is that it is not
available in tuscany as of today. Please correct me if I am wrong.

(b) This was point (c) in Sebastien's mail.
  I want to use a Web app in my SCA assembly and call SCA components
  from it. I should be able to declare an SCA component representing my
  Web app, wire that component to other SCA components in the assembly,
  and then magically the wired references will be available as proxies for
  use in my JSPs, allowing me to call an SCA component using a simple
  jsp:useBean tag.

In addition to this the J2EE integration whitepaper at the OSOA
site mentions abt being able to annotate Web
artifacts(servlets,filters etc) with the SCA Annotations and get
services injected into servlets/filters etc for usage. The wiring will
be done by the SCA runtime. The whitepaper is here
http://www.osoa.org/pages/viewpage.action?pageId=3980.

The things to be done for achieving this functionality are,

1) Create a new implementation type in Tuscany namely implementation.web.
2) Declare in a .composite file in the war that the war is an
implementation.web type
3) The implementation.web tuscany extension will have functionality
to introspect the web module classes for SCA specific annotations and
build up information. Since there is a single SCADomain instance per
server and all the services that we are going to reference are already
deployed there, the implementation.web extension will take care of
wiring and creating service proxies. These proxies will be bound to
jndi.

The injection into geronimo managed objects cannot be done by tuscany
runtime. I am not 100% sure but I think that if I can populate the
injectionMap in the Holder object in the TomcatWebAppContext GBean for
that war with the right information then the injection will be taken
care of by Geronimo. Can someone confirm this?
This will take care of the integration in these two cases. As of now
we are assuming all the services to of scope stateless. All the stuff
in the second case will be done in a deployment watcher after a war
has been deployed.

This is the approach that myself and Vamsi are planning to use. If
there is any problem with this approach that you can see or a better
way to do things or something in the mail is not clear, please fell
free to point it out.

Regards
Manu

On 6/29/07, Paul McMahan [EMAIL PROTECTED] wrote:

On Jun 29, 2007, at 3:11 AM, Manu George wrote:

 
  Some of the questions we have are:
  1.  Should we use this plugin approach and host the plugin
 separatley
  or

Re: [DISCUSS] Geronimo 2.1 - what's next?

2007-07-03 Thread Paul McMahan


On Jul 2, 2007, at 12:07 PM, Matt Hogstrom wrote:

*Dynamic Console for managing installed artifacts*

Improve the console framework to allow installed artifacts to  
register a portlet for managing the configuration.  For highest  
level of flexibility a component would provide the required portlet  
elemtns and we would bind them into the navigation framework and  
security infracstructure.  We'd need a good set of docs and samples  
to help people in deploying this easy.  Ideally we would start with  
a minimal assembly and a mgmt console so that new functions could  
be loaded through the console.  I'm not sure that we'd need to have  
an assembly smaller than minimal at this point since we'd need a  
web container for the mgmt console anyway.


I'm a huge fan of this idea as it will allow us to provide a console  
for the minimal assembly that can scale up to the full JEE5 console  
in a step-wise fashion.  Also it allows geronimo users/developers to  
add portlets to the admin console for administering their  
components.  Another advantage is that we can provide a more  
streamlined console for the JEE5 assemblies and allow the user to add  
the heavier weight views (like the ones that require Dojo) on demand  
from the plugin installer.


The stuff in sandbox/portals is making some good progress towards  
this goal.  I'll send an update on that effort soon.


Best wishes,
Paul

[jira] Commented: (GERONIMODEVTOOLS-141) Installation/Activation of Plugin fails

[
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509910
]

Paul Grove commented on GERONIMODEVTOOLS-141:
-

I think this should be re-opens as I take back what I said before about it all
working. All works in terms of running Geronimo but if I try to add any new
plug-in's from an update site totally unrelated to Geronimo I get this error
when I select a feature to install Geronimo v1.0 Server Adapter (2.0.0)
requires feature org.eclipse.jst (1.6.0), or compatible. I can then not
update Eclipse anymore :-(

Installation/Activation of Plugin fails
---

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

[jira] Commented: (GERONIMODEVTOOLS-141) Installation/Activation of Plugin fails


[ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509911
 ] 

Paul Grove commented on GERONIMODEVTOOLS-141:
-

As per my comment above the Version of org.eclipse.jst that comes with Europa 
is1.0.2.v200706120315

 Installation/Activation of Plugin fails
 ---

 Key: GERONIMODEVTOOLS-141
 URL: 
 https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-141
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 1.2.0
 Environment: Windows XP SP2, Java 1.6.0_01, Eclipse 3.3 M6, WST 2.0 M6
Reporter: Stefan
Assignee: Sachin Patel
Priority: Blocker

 Via Eclipse function to download additional server adapters you can choose 
 and install the plugin.
 But after restart Eclipse the plugin is disabled. If you try to enable it, 
 you get:
 Requested operation cannot be performed because it would invalidate the 
 current configuration. See details for more information. 
 org.apache.geronimo.feature (1.2.0) requires plug-in 
 com.ibm.etools.emf.event.

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

[jira] Commented: (GERONIMODEVTOOLS-141) Installation/Activation of Plugin fails


[ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509917
 ] 

Paul Grove commented on GERONIMODEVTOOLS-141:
-

Sorry having a bad afternoon the version should be 2.0.0 this is shipped with 
Europa need to update all the feature.xml files so that 
requires
import feature=org.eclipse.jst version=2.0.0 match=compatible/
/requires

not

requires
import feature=org.eclipse.jst version=1.6.0 match=compatible/
/requires

I have made these changes in all the Geronimo feature.xml files and I can now 
update from update sites once again!!:-)

 Installation/Activation of Plugin fails
 ---

 Key: GERONIMODEVTOOLS-141
 URL: 
 https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-141
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 1.2.0
 Environment: Windows XP SP2, Java 1.6.0_01, Eclipse 3.3 M6, WST 2.0 M6
Reporter: Stefan
Assignee: Sachin Patel
Priority: Blocker

 Via Eclipse function to download additional server adapters you can choose 
 and install the plugin.
 But after restart Eclipse the plugin is disabled. If you try to enable it, 
 you get:
 Requested operation cannot be performed because it would invalidate the 
 current configuration. See details for more information. 
 org.apache.geronimo.feature (1.2.0) requires plug-in 
 com.ibm.etools.emf.event.

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

[jira] Updated: (GERONIMO-3269) Console:some parameters remains original when restarted


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

Donald Woods updated GERONIMO-3269:
---

  Component/s: (was: console)
   kernel
 Priority: Critical  (was: Major)
Fix Version/s: 2.0-M7

Updating to Critical for 2.0-M7.

 Console:some parameters remains original when restarted  
 -

 Key: GERONIMO-3269
 URL: https://issues.apache.org/jira/browse/GERONIMO-3269
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: kernel
Affects Versions: 2.0-M6
 Environment: Windows 2003/XP
Reporter: Song
Priority: Critical
 Fix For: 2.0-M7

 Attachments: GERONIMO-3269-1.patch, geronimo-3269.patch


 steps as below can reproduce the error:
  1) create database pool EmployeeDatasource from console successfully
  2) Click on edit link next to EmployeeDatasource
  3) Modify some parameters like Pool Max Size from 10 to 50, Idle Timeout 
 from 15 to 30, click on Save button
  4) Under J2EE Connectors,click on Stop, then click Start
  5) parameters Pool Max Size return to 10, and Idle Timeout also changed 
 to original 15
  
  6) If skip 4),click on restart, the modification will take effect. 

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

Re: [DISCUSS] Geronimo 2.1 - what's next?

2007-07-03 Thread Jay D. McHugh

I was also thinking about the delivered server (since we have been 
discussing footprint).


Perhaps we could deliver Geronimo as two pieces:
1) A minimal server that provides a console for adding plugins or plugin 
'packages' (ie: certified jee5 tomcat server)

2) An archived plugin repository.

If someone knows that they will be able to access the online plugin 
repository, then they would only need to download the basic server (nice 
and small) and add plugins as needed.


Hopefully, that will avoid all of the transitive dependency and unneeded 
module issues.


We could decide what combinations we wanted to certify on and provide 
those as templates (or profiles or packages or whatever name we came up 
with for them) for easy installation.


And, if users put together combinations that they thought might be 
useful for others - they could possibly upload them as a package profile 
(or at least email them around).


That would add a step for someone who wanted to just download a JEE5 
server - but it would emphasize that Geronimo is more than just a JEE 
server.


Jay

Matt Hogstrom wrote:
Seems like the dev list has been  a bit quiet lately as I know many 
folks have been working on getting 2.0 done and through some 
additional testing for Axis, fit and finish stuff, etc.  Although 
important, its not exactly the next generation so I thought I'd start 
this thread to get some ideas formed around the next step for AG.  
These are just my thoughts and I'm soliciting input for ideas and 
discussion.


I thought I'd put my thoughts in the form of a user describing what 
they need from Geronimo.  This is based on input I've heard from 
several folks as well as users and includes some of my own ideas as 
well.  It feels like we've been chasing the specs for so long that we 
haven't fully realized some of the other awesome ideas people have 
had.  Aaron's plugin architecture is workable but not fully 
consumable, Dain's repository work and a host of other ideas.  I think 
now is the time to have some fun.To that end here is the list of 
requirements.


Geronimo 2.1 Punch List

*Flexible framework for building server assemblies that include only 
the components needed for an application*


This means that a user could either build a custom assembly with only 
the needed parts or, alternatively, could run with all parts available 
but only start what they need.  The model is up to the user to decide 
based on their unique requirements.


*Dynamically binding needed elements*

Using the plugin architecture and Maven repo concepts one could 
install a needed element into the server by simply pointing to a 
remote repository and installing the element.  Other artifacts needed 
for execution would be obtained automagically from either the network 
or a shared filesystem as needed and based on the policies provided by 
the user.  The default mode of operation would provide the best user 
experience.


*Dynamic Console for managing installed artifacts*

Improve the console framework to allow installed artifacts to register 
a portlet for managing the configuration.  For highest level of 
flexibility a component would provide the required portlet elemtns and 
we would bind them into the navigation framework and security 
infracstructure.  We'd need a good set of docs and samples to help 
people in deploying this easy.  Ideally we would start with a minimal 
assembly and a mgmt console so that new functions could be loaded 
through the console.  I'm not sure that we'd need to have an assembly 
smaller than minimal at this point since we'd need a web container for 
the mgmt console anyway.


*Cluster Aware Mgmt Application*

For users that want to federate a number of servers together we need a 
clustering solution that will allow for configuration of nodes as well 
as autodiscovery.  This requires a clustering element for Geronimo 
that takes into account multiple clustering users (services).  I think 
Jeff has some of the foundation in GCache.



*SOA Assembly*
It would be great to have a SOA assembly (that works in a flexible way 
:) with AMQ, ServiceMix and a Tx Manager.  A LOT of people I talk to 
want something simple like a Tomcat and a Mule...let's give it to them.



*Tooling*
A really huge part of what people have talked about as being important 
is tooling integration (I've heard mostly about Eclipse and NetBeans).



*OSGi and Spring*
This has been kicked around for a long time.  I was talking with 
someone who said they needed a flexible runtime that would allow them 
to wire in OSGi bundles (seems like the traction is increasing) and 
use Spring for the configuration.  People smarter than I can weigh in 
on this area but this is seems to get Independent Software Vendors 
(ISV's) all hot under the collar.  If we could deliver this with the 
flexible server stuff I think we'd have a huge swell of interest.



Other thoughts?

Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)

2007-07-03 Thread Raymond Feng


Hi,

Please see my comments inline.

Thanks,
Raymond

- Original Message - 
From: Manu George [EMAIL PROTECTED]

To: dev@geronimo.apache.org
Cc: [EMAIL PROTECTED]
Sent: Tuesday, July 03, 2007 7:53 AM
Subject: Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)



Hi ,
   From Paul's mail I guess a Geronimo plugin would be
the way forward. I am going to list down a few more questions on the
scenarios that Sebastien has explained. The scenarios are given first
and then my understanding, approach and issues. I would be just
listing two of the scenarios and trying to implement them initially.

(a) I develop SCA components, assemble them in a composite, package them
in an SCA contribution. I don't really know what a WAR or an EAR is, 
I'm

just using the SCA programming model and packaging model. I deploy my
SCA contribution to Geronimo and run it there.

This will require a tuscany specific deployer that is installed as
part of the plugin. Ususally deployers have access to a server
specific deployment plan at some fixed path say
(META-INF/geronimo-tuscany.xml). If this file is found then the
deployer will know that the module that was supplied to it is a
tuscany module. In case I am deploying a tuscany contribution using
the sca packaging model then there will be a .composite file somewhere
in the module and the deployer will have to search in the module for
scdl files.  For now the tuscany  contributions will always be
packaged as jars.


I'm not a geronimo expert. My understanding is that the Tuscany deployer 
needs a way to recognize the archive is a SCA contribution. It could
be an external deployment plan such as genronimo-tuscany.xml. If the 
deployment plan is not present, then a SCA deployment descriptor will be
checked. The SCA assembly spec doesn't define a mandatory deployment 
descriptor. We might be able to use META-INF/sca-contributions.xml as

a starting point.



This will mean that if the deployer finds this file then it will
handle the module as a tuscany module and if not found relinquish
control to other deployers.



The SCA contribution itself can be an EAR. I assume an archive can be 
processed by multiple deployers.



Now we come to the question of the Domain. This has been a vexing
question for me. I think that going for a single SCADomain for the
entire server would be a good place to start.
All the applications will have an application composite and that
composite will be deployed on the server wide SCADomain. What the
server wide SCADomain should provide is the ability to add and remove
composites at runtime. If I am not mistaken this will be supported by
the EmbeddedSCADomain. Can someone in the know comment on this.


We can start with a local SCA domain for the Geronimo server. 
EmbeddedSCADomain is the right class and it can be extended to support the 
Geronimo host.




The other logical approach would be to go for different partial
SCADomain instances per contribution. These different instances will
still have information about the other instances and will do the
wiring across the instances that constitute a complete SCADomain.
From what I could find, this type of an SCADomain is not
supported currently. There is work on an SCADomain spanning multiple
runtimes. This would be a simpler case of an SCADomain spanning
multiple classloaders or (configurations in Geronimo).



SCADomain can span multiple runtimes. Simon Laws from Tuscany is driving the 
support of distributed SCADomain. I'm a bit confused by the statement

different partial SCADomain instances per contribution. Can you clarify?


The reason for not going with the second approach is that it is not
available in tuscany as of today. Please correct me if I am wrong.

(b) This was point (c) in Sebastien's mail.
  I want to use a Web app in my SCA assembly and call SCA components
  from it. I should be able to declare an SCA component representing 
my
  Web app, wire that component to other SCA components in the 
assembly,
  and then magically the wired references will be available as proxies 
for

  use in my JSPs, allowing me to call an SCA component using a simple
  jsp:useBean tag.

In addition to this the J2EE integration whitepaper at the OSOA
site mentions abt being able to annotate Web
artifacts(servlets,filters etc) with the SCA Annotations and get
services injected into servlets/filters etc for usage. The wiring will
be done by the SCA runtime. The whitepaper is here
http://www.osoa.org/pages/viewpage.action?pageId=3980.

The things to be done for achieving this functionality are,

1) Create a new implementation type in Tuscany namely implementation.web.
2) Declare in a .composite file in the war that the war is an
implementation.web type
3) The implementation.web tuscany extension will have functionality
to introspect the web module classes for SCA specific annotations and
build up information. Since there is a single SCADomain

Re: [DISCUSS] Split container and components release cycles ?

2007-07-03 Thread Eduardo Burgos


I vote for not splitting releases. The way it is now, we dont need to worry
about versions as everything is the same number. External components (like
Apache Ode) have their own versions already so...



On 7/3/07, Guillaume Nodet [EMAIL PROTECTED] wrote:


I was mainly refering to the examples that come with the default
distribution of
ServiceMix.  The distribution includes the container, some configuration
files,
JBI components and demos.

We already have some TCK stuff which is not available publicly due to the
need
for an NDA mainly.

But I agree with you on the test harness, integration tests and all.

On 7/3/07, Kit Plummer [EMAIL PROTECTED] wrote:
 On 7/3/07, Guillaume Nodet [EMAIL PROTECTED] wrote:
  If we go that way, how could we deal with the examples ?
  I guess they would either require the use to download the components,
  or be available on a separate distros (and thus have their own
  release cycle too).
 
  On 7/2/07, Guillaume Nodet [EMAIL PROTECTED] wrote:
   I'd like to start a discussion on splitting the container and
   components release cycles.   What do people think about that ?
   Should we keep the container and all the components in a single
   release like we have done so far, or should we split these releases
   and release the components separately from the container ?
  
   --
   Cheers,
   Guillaume Nodet
   
   Principal Engineer, IONA
   Blog: http://gnodet.blogspot.com/
  
 
 
  --
  Cheers,
  Guillaume Nodet
  
  Principal Engineer, IONA
  Blog: http://gnodet.blogspot.com/
 

 Testing the integration of multiple components?  Is this what you mean
 by examples Guillaume?

 Yes, this could be tricky.   There needs to be a JBI TCKish thing,
 that can evaluate BCs, SEs and SAs too.  Something that can validate
 compliance...

 I realize this is probably a bit off-track from where the division
 discussion was going - but, in the end there needs to be a way to
 ensure components work - without a manual integration.  Test cases can
 handle some of the load - say for stock components.  But, it will
 most likely be up to the component developers to do the testing (and
 it would be nice if there was  an easy test harness to drop the
 component in to to validate.

 Kit



--
Cheers,
Guillaume Nodet

Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/

[jira] Created: (GERONIMO-3300) Upgrade Dojo to 0.9

Upgrade Dojo to 0.9
---

 Key: GERONIMO-3300
 URL: https://issues.apache.org/jira/browse/GERONIMO-3300
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: console
Affects Versions: 2.0-M7
Reporter: Jay D. McHugh
Assignee: Jay D. McHugh


The new Dojo 0.9 Beta was just released.

It will reduce the footprint of the main dojo.js to under 50k - But will 
require that some of the console
screens to be reworked because the widget system was completely redesigned and 
is incompatible.

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

[jira] Updated: (GERONIMO-3069) Rework AJAX style console screens to work on Safari


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

Jay D. McHugh updated GERONIMO-3069:


Issue Type: Sub-task  (was: Bug)
Parent: GERONIMO-3300

 Rework AJAX style console screens to work on Safari
 ---

 Key: GERONIMO-3069
 URL: https://issues.apache.org/jira/browse/GERONIMO-3069
 Project: Geronimo
  Issue Type: Sub-task
  Security Level: public(Regular issues) 
  Components: console
Affects Versions: 2.0-M7
Reporter: Jay D. McHugh
Assignee: Jay D. McHugh
 Attachments: geronimo-3069-jmx-1.patch


 Some of the newer console screens do not work properly in Safari.
 Try to rewrite the javascript code so that it works on safari.

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

[jira] Updated: (GERONIMO-3050) Create a JPA persistence unit view for the console


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

Jay D. McHugh updated GERONIMO-3050:


Issue Type: Sub-task  (was: Improvement)
Parent: GERONIMO-3300

 Create a JPA persistence unit view for the console
 --

 Key: GERONIMO-3050
 URL: https://issues.apache.org/jira/browse/GERONIMO-3050
 Project: Geronimo
  Issue Type: Sub-task
  Security Level: public(Regular issues) 
  Components: console
Affects Versions: 2.0-M7
Reporter: Jay D. McHugh
Assignee: Jay D. McHugh

 Create one or more JPA views that show:
  - View of loaded persistence units (tree format with persistable classes 
 under each unit)
  - View of loaded persistence units detailing their properties (back-end 
 database, transaction mode, ...) 

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

[jira] Commented: (GERONIMO-3300) Upgrade Dojo to 0.9


[ 
https://issues.apache.org/jira/browse/GERONIMO-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510023
 ] 

Donald Woods commented on GERONIMO-3300:


When is 0.9 supposed to be released?  We shouldn't upgrade to a Beta level when 
we are within weeks of trying to release 2.0

 Upgrade Dojo to 0.9
 ---

 Key: GERONIMO-3300
 URL: https://issues.apache.org/jira/browse/GERONIMO-3300
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: console
Affects Versions: 2.0-M7
Reporter: Jay D. McHugh
Assignee: Jay D. McHugh

 The new Dojo 0.9 Beta was just released.
 It will reduce the footprint of the main dojo.js to under 50k - But will 
 require that some of the console
 screens to be reworked because the widget system was completely redesigned 
 and is incompatible.

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

Re: Atkins for Geronimo - was Re: [DISCUSS] 2.0 Release Criteria

2007-07-03 Thread Donald Woods

+1 as this would provide a common schema for other vendor implementations 
(like MySQL, Oracle, DB2, ...)


-Donald

David Jencks wrote:


On Jun 28, 2007, at 10:38 AM, Kevan Miller wrote:



On Jun 28, 2007, at 12:35 PM, Jay D. McHugh wrote:

The page has been updated to move the contents of repository/geronimo 
to repository/org/apache/geronimo.


I found a couple of other places where contents of the repository 
moved (tranql - org/tranql, etc) and fixed those as well.


If anyone sees a module that moved (that I missed) let me know and 
I'll rework the table.


I already caught org/apache/geronimo/activemq-broker(1.2) s/b 
org/apache/geronimo/configs/activemq-broker but haven't fixed it 
yet.  For sizing purposes, that will not affect the following results.


Here are the places that I am seeing that the repository has grown 
(between 1.1.1 and 2.0):


Added (size rounded to nearest Meg)
com/sun/xml (5M)
commons-codec (1M)
commons-fileupload (1M)
commons-httpclient (1M)
commons-io (1M)
commons-jexl (1M)
commons-lang (1M)
commons-primitives (1M)
directory (1M)
directory-asn1 (1M)
directory-network (1M)
directory-protocols (1M)
directory-shared (1M)
dwr (1M)
javax (1M)
jaxen (1M)
jdbm (1M)
jline (1M)
jstl (1M)
net (1M)
ognl (1M)
org/apache/axis2 (3M)
org/apache/bcel (1M)
org/apache/cxf (2M)
org/apache/httpcomponents (1M)
org/apache/myfaces (1M)
org/apache/neethi (1M)
org/apache/openjpa (3M)
org/apache/ws/commons/axiom (1M)
org/apache/yoko (4M)
org/codehaus/castor (3M)
org/codehaus/swizzle (1M)
org/sl4j (1M)
org/springframework (1)
oro (1M)
regexp (1M)
woodstox (1M)
xml-resolver (1M)

Grew (growth rounded to nearest Meg)
org/apache/activemq (1M)
org/apache/geronimo (Some additions, some reductions: 8M overall - 
~5M of this is dojo)

org/apache/tomcat (1M)
org/apache/xbean (1M) - We have 3.0 snapshot and 3.1 snapshot in 2.0

Those are only the increases.  There may be more, but these were the 
ones that I caught (there are still some moved module issues yet to 
be found).  As best as I could tell, upgrades between versions of the 
same component did not significantly contribute to the increase in 
footprint.  Additional components is where we got hit the hardest.


Nice. Thanks for doing this Jay and Prasad...

Nothing really jumps out at me as being unnecessary... Just scanning 
that list for the big hitters...


com/sun (5M) is new
org/apache/yoko (4M) is new
org/apache/castor (3M) is new. OpenEJB is no longer dependent on 
castor (IIRC) We could look to see who else is dependent on it...

org/apache/openjpa (3M) is new.
org/apache/axis2 (3M)
org/apache/cxf (2M) is new.

All, except perhaps castor, are needed...


If we really wanted to cut down on carbs, we could ask ourselves if we 
really need to package Dojo. That would save 5 megs.


The only thing worth spending much time on, IMO, are Geronimo configs. 
By my count, configs in 2.0 is 15 Meg. In 1.1.1 they were 3.5 Megs 
(repository/geronimo/geronimo-*)


Should definitely look at is moving jar files (especially the 
redundant ones) out of org/apache/geronimo/configs. As in:


./activemq-ra/2.0-SNAPSHOT/activemq-ra-2.0-SNAPSHOT.car/rar/activemq-core-4.1.1.jar 

./activemq-ra/2.0-SNAPSHOT/activemq-ra-2.0-SNAPSHOT.car/rar/activemq-ra-4.1.1.jar 

./ca-helper-jetty/2.0-SNAPSHOT/ca-helper-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/geronimo-ca-helper-2.0-SNAPSHOT.jar 

./dojo-jetty6/2.0-SNAPSHOT/dojo-jetty6-2.0-SNAPSHOT.car/WEB-INF/lib/geronimo-dojo-2.0-SNAPSHOT.jar 

./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/asm-2.2.3.jar 

./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/asm-commons-2.2.3.jar 

./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/asm-tree-2.2.3.jar 

./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/cglib-nodep-2.1_3.jar 

./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/commons-logging-1.0.4.jar 

./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/geronimo-kernel-2.0-SNAPSHOT.jar 

./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/geronimo-remote-deploy-2.0-SNAPSHOT.jar 

./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/log4j-1.2.14.jar 

./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/xpp3-1.1.3.3.jar 

./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/xstream-1.1.3.jar 

./system-database/2.0-SNAPSHOT/system-database-2.0-SNAPSHOT.car/rar/tranql-connector-1.3.jar 

./system-database/2.0-SNAPSHOT/system-database-2.0-SNAPSHOT.car/rar/tranql-connector-derby-common-1.3.jar 

./uddi-jetty6/2.0-SNAPSHOT/uddi-jetty6-2.0-SNAPSHOT.car/uddi-db/tranql-connector-1.3.jar 

./uddi-jetty6/2.0-SNAPSHOT/uddi-jetty6-2.0-SNAPSHOT.car/uddi-db/tranql-connector-derby-common-1.3.jar

[jira] Updated: (GERONIMO-3299) ejb 3.0 annotation converter for j2g


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

Viet Hung Nguyen updated GERONIMO-3299:
---

Attachment: geronimo-3299.patch

this patch adds the ability to convert jboss-supported annotations to 
geronimo's equivalent.

 ejb 3.0 annotation converter for j2g
 

 Key: GERONIMO-3299
 URL: https://issues.apache.org/jira/browse/GERONIMO-3299
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: J2G
 Environment: windows xp
Reporter: Viet Hung Nguyen
 Attachments: geronimo-3299.patch


 We need to be able to convert JBoss EJB annotations (which are sometimes 
 supported by JBoss and not Geronimo) to what Geronimo supports.

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

[jira] Commented: (GERONIMO-3269) Console:some parameters remains original when restarted


[ 
https://issues.apache.org/jira/browse/GERONIMO-3269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510033
 ] 

Donald Woods commented on GERONIMO-3269:


I'm holding off committing this patch, as I would like someone with more 
kernel/deployer experience to review it first

 Console:some parameters remains original when restarted  
 -

 Key: GERONIMO-3269
 URL: https://issues.apache.org/jira/browse/GERONIMO-3269
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: kernel
Affects Versions: 2.0-M6
 Environment: Windows 2003/XP
Reporter: Song
Priority: Critical
 Fix For: 2.0-M7

 Attachments: GERONIMO-3269-1.patch, geronimo-3269.patch


 steps as below can reproduce the error:
  1) create database pool EmployeeDatasource from console successfully
  2) Click on edit link next to EmployeeDatasource
  3) Modify some parameters like Pool Max Size from 10 to 50, Idle Timeout 
 from 15 to 30, click on Save button
  4) Under J2EE Connectors,click on Stop, then click Start
  5) parameters Pool Max Size return to 10, and Idle Timeout also changed 
 to original 15
  
  6) If skip 4),click on restart, the modification will take effect. 

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

[jira] Commented: (GERONIMO-3300) Upgrade Dojo to 0.9


[ 
https://issues.apache.org/jira/browse/GERONIMO-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510038
 ] 

Jay D. McHugh commented on GERONIMO-3300:
-

It will be a while before I have completed the changes to allow a switch to 0.9.

If I manage to finish before the final release comes out - Then I'll wait until 
it does.

I just wanted to organize the subtasks under the larger task of upgrading so 
that
I wouldn't be doing the work twice (once under 0.4.3 and then again under 0.9).

This will probably end up being for 2.0.1.

 Upgrade Dojo to 0.9
 ---

 Key: GERONIMO-3300
 URL: https://issues.apache.org/jira/browse/GERONIMO-3300
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: console
Affects Versions: 2.0-M7
Reporter: Jay D. McHugh
Assignee: Jay D. McHugh

 The new Dojo 0.9 Beta was just released.
 It will reduce the footprint of the main dojo.js to under 50k - But will 
 require that some of the console
 screens to be reworked because the widget system was completely redesigned 
 and is incompatible.

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

[jira] Commented: (GERONIMO-3300) Upgrade Dojo to 0.9