Picon
Favicon

[jira] [Commented] (GERONIMO-6005) Unclear how big a cdi context is for an ear


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

Mark Struberg commented on GERONIMO-6005:
-----------------------------------------

I actually don't understand the term 'context' in this regard. I can only guess that you are referring to the
problem that  <at> ApplicationScoped might be underspecified. There is currently an open CID issue
https://issues.jboss.org/browse/CDI-129

Please note that CDI-18 is also related to this issue. The currently specified BDA ('Bean Archive')
behaviour is not usable at all and even JBoss, Glassfish and WebLogic do _not_ implement it as strict as the
spec states (1 JAR == 1 BDA) but relaxed the restrictions a bit (but different on each server). I'm sure I
don't need to say that this is seriously broken ...

So far my (long) discussions with Pete seems to come to the following conclusion (discussions not yet
finished): We need to think hard about re-introducing the 'hierarchic' BeanManager as it has been in the
Spec shortly before the spec got finished. 

The BeanManager hierarchy setup would depend on the situation in the container, most likely 1:1 with the
ClassLoader Hierarchy. 

Means 1 BeanManager for the EAR would scan all the shared ear/lib ejb-jar.xml JAR files. Each WebApp would
additionally get it's own BeanManager which would only manage it's own Bean<T> and delegates to the
shared Ear-BeanManager.

 This is needed due to how each javax.enterprise.context.spi.Context works internally. Each Context
(e.g. a Context for  <at> EnterpriseApplicationScoped) has a Map<Contextual<T>, T> and
(Continue reading)

Picon
Favicon

[jira] [Created] (GERONIMO-6249) use RecursiveBundleTracker instead of bundle listener

use RecursiveBundleTracker instead of bundle listener
-----------------------------------------------------

                 Key: GERONIMO-6249
                 URL: https://issues.apache.org/jira/browse/GERONIMO-6249
             Project: Geronimo
          Issue Type: Bug
      Security Level: public (Regular issues)
          Components: core
    Affects Versions: 3.0
            Reporter: David Jencks
            Assignee: David Jencks
             Fix For: 3.0

We should be using BundleTracker anyway, but since we are considering region support we need
RecursiveBundleTracker to pick up all the bundle events, not just the ones visible from the current region.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Picon
Favicon

[jira] [Issue Comment Edited] (GERONIMO-5800) logged-in Subjects are cleaned up after web requests complete


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

David Frahm edited comment on GERONIMO-5800 at 1/3/12 2:52 PM:
---------------------------------------------------------------

I understand and respect the fact that this is open source and free software, so this is NOT a complaint.  I'm
just trying to figure a strategy moving forward with our apps on this platform.

Any ideas on if/when this might be fixed?  This seems like the kind of issue that would be a very big deal to many
users, but maybe its just me?

My linux/geronimo servers run for about a week and then need to be restarted.  I've got a cron job that does it,
but that sometimes causes other issues and is way more downtime than we're used to requiring.  Plus, it just
seems so wrong ;-)

On another note, we are working on some official IBM WASCE support.  Would that help to get this
resolved/patched or are they just going to diagnose and tell me what I already know?

                
      was (Author: dfrahm@...):
    Any ideas on if/when this might be fixed?  This seems like something that would be a very big deal, but maybe
its just me?

My linux/geronimo servers run for about a week and then need to be restarted.  I've got a cron job that does it,
but that is way more downtime than we're used to requiring.  Plus, it just seems so wrong ;-)

I understand and respect the fact that this is open source and free software, so this is NOT a complaint.  I'm
(Continue reading)

Yi Xiao | 4 Jan 2012 03:05
Picon

Re: About GEP2.1.8 release

Hi Forrest,

Thank you very much for your help. I'm working on it

On Wed, Dec 28, 2011 at 7:59 PM, Forrest Xia <forrestxm <at> gmail.com> wrote:


On Wed, Dec 28, 2011 at 2:50 PM, Yi Xiao <xiaoyijhondevelop-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Hi devs,

I notice the vote of Geronimo 2.1.8 is already passed, so I wonder if we could do the release of GEP2.1.8 now? if so, I am very glad to be the volunteer,  could somebody help me?

It's good we could have a GEP release for 2.1.8.

To make a community release, I think we need to do these things in order:
1. Open a wiki page to track
2. Clean up the jiras
3. Make the build
4. Do release stuff
5. Raise vote
6. Do announcement

In case there are some things only doable by committer, I can help.

Anyway, thank you for be volunteer!

--
Best regards!

                                                                                            John Xiao




--
Thanks!

Regards, Forrest




--
Best regards!

                                                                                            John Xiao

Picon
Favicon

[jira] [Created] (GERONIMO-6250) Allow definition of maxParameterCount in gbean

Allow definition of maxParameterCount in gbean
----------------------------------------------

                 Key: GERONIMO-6250
                 URL: https://issues.apache.org/jira/browse/GERONIMO-6250
             Project: Geronimo
          Issue Type: Improvement
      Security Level: public (Regular issues)
          Components: Tomcat
    Affects Versions: 2.1.8
            Reporter: Forrest Xia

maxParameterCount is a new parameter of Tomcat since 6.0.35, we need to update the gbean to allow its
definition in Geronimo way.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Yi Xiao (Created) (JIRA | 4 Jan 2012 08:59
Picon
Favicon

[jira] [Created] (GERONIMODEVTOOLS-778) Using GEP3.0.X's eclipse/build.xml to replace the GEP2.1.X's

Using GEP3.0.X's eclipse/build.xml to replace the GEP2.1.X's
------------------------------------------------------------

                 Key: GERONIMODEVTOOLS-778
                 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-778
             Project: Geronimo-Devtools
          Issue Type: Task
          Components: eclipse-plugin
    Affects Versions: 2.1.8
            Reporter: Yi Xiao
            Assignee: Yi Xiao

The build.xml in GEP3.0.x supports the latest eclipse3.7SR1 and is more graceful than GEP2.1.x's.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Yi Xiao (Updated) (JIRA | 4 Jan 2012 09:05
Picon
Favicon

[jira] [Updated] (GERONIMODEVTOOLS-778) Using GEP3.0.X's eclipse/build.xml to replace the GEP2.1.X's


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

Yi Xiao updated GERONIMODEVTOOLS-778:
-------------------------------------

    Attachment: usingGep3.0AntScriptInEclipse_778.patch

Update the gep2.1's eclipse/build.xml

> Using GEP3.0.X's eclipse/build.xml to replace the GEP2.1.X's
> ------------------------------------------------------------
>
>                 Key: GERONIMODEVTOOLS-778
>                 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-778
>             Project: Geronimo-Devtools
>          Issue Type: Task
>          Components: eclipse-plugin
>    Affects Versions: 2.1.8
>            Reporter: Yi Xiao
>            Assignee: Yi Xiao
>              Labels: ant, build.xml
>         Attachments: usingGep3.0AntScriptInEclipse_778.patch
>
>
> The build.xml in GEP3.0.x supports the latest eclipse3.7SR1 and is more graceful than GEP2.1.x's.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Yi Xiao | 4 Jan 2012 10:02
Picon

Re: About GEP2.1.8 release

Hi Forrest,

I've done the following works:
1 successfully build the branch2.1.8-snapshot
2 Done the rat check
3 Update PLUGIN_RELEASE-NOTES-2.1.8.txt according to the jiras

Could you please do the release: prepare and perform? Tank you very much!

On Wed, Dec 28, 2011 at 7:59 PM, Forrest Xia <forrestxm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:


On Wed, Dec 28, 2011 at 2:50 PM, Yi Xiao <xiaoyijhondevelop-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Hi devs,

I notice the vote of Geronimo 2.1.8 is already passed, so I wonder if we could do the release of GEP2.1.8 now? if so, I am very glad to be the volunteer,  could somebody help me?

It's good we could have a GEP release for 2.1.8.

To make a community release, I think we need to do these things in order:
1. Open a wiki page to track
2. Clean up the jiras
3. Make the build
4. Do release stuff
5. Raise vote
6. Do announcement

In case there are some things only doable by committer, I can help.

Anyway, thank you for be volunteer!

--
Best regards!

                                                                                            John Xiao




--
Thanks!

Regards, Forrest




--
Best regards!

                                                                                            John Xiao

Forrest Xia | 4 Jan 2012 10:21
Picon

Re: Some history releases gone?



On Fri, Dec 30, 2011 at 5:39 AM, Kevan Miller <kevan.miller-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

On Dec 29, 2011, at 1:30 PM, Jay D. McHugh wrote:

> Hey Forrest,
>
> The download links for the older versions are supposed to have been updated to point to the archives (http://archive.apache.org/dist/geronimo/).
>
> Just for the purpose of cleanup of the dist folder.
>
> They all still exist.  I am actually surprised at how many are still available on the regular download location.
Today I checked the links of those history releases, and found they are updated with the archive links now. Not sure this happened automatically or manually?

Right. We should only have the latest release in our dist directory.

It's probably time to delete some of our older versions from dist (and only include them in archive). We should also make a formal statement of support, IMO. If problems are found in versions 2.0 and older versions (e.g. 1.1). I don't think we plan on making any fixes…
Where we shall put the support lifecycle statement on our web site? The download page http://geronimo.apache.org/downloads.html?

--kevan



--
Thanks!

Regards, Forrest

Forrest Xia | 4 Jan 2012 10:32
Picon

Re: Geronimo 3 and karaf 3

I got some time to try the trunk change locally after G 2.1.8 release stuffs are basically done :-)

Several findings about the trunk changes:
1. The server trunk can only be compiled with Maven 3, that's the reason it failed to compile in the TCK environment(the maven version used in TCK env is 2.2.1). I will update the TCK env in the coming days.
2. The testsuite cannot be executed since geronimo-maven-plugin cannot launch the server now. This issue will also block TCK execution.
3. The command line interfaces has big changes, I cannot find startup/shutdown/geronimo scripts now. I do not look into the changes further, so I even don't know how to launch the server now.

So generally, I think we need a introduction about how to use the trunk build now.

On Thu, Dec 22, 2011 at 5:14 PM, Forrest Xia <forrestxm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:


On Thu, Dec 22, 2011 at 2:27 AM, David Jencks <david_jencks-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> wrote:
I pushed a karaf snapshot.... maybe that will help?  I don't see this problem locally.
No help for server build in AHP, I will try it locally. thanks!
 

thanks
david jencks

On Dec 21, 2011, at 8:18 AM, Forrest Xia wrote:

Trunk build failed with this error when building a new module Geronimo Framework, Feature :: DS and Metatype

 [INFO] Internal error in the plugin manager executing goal 'org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT:features-generate-descriptor': Unable to find the mojo 'features-generate-descriptor' (or one of its required components) in the plugin 'org.apache.karaf.tooling:karaf-maven-plugin'
 Component descriptor cannot be found in the component repository: org.sonatype.aether.RepositorySystem.


On Tue, Dec 20, 2011 at 2:06 PM, David Jencks <david_jencks-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> wrote:
BTW, to get the regions/isolation stuff working I think we are going to need to replace our use of BundleListener/SynchronousBundleListener with the (updated-for-4.3) aries RecursiveBundleTracker.  I think we'll need also change from ConfigurationActivator to an extender pattern.  I'd guess the ConfigurationActivator functionality could be moved to DependencyManager rather than having an additional tracker.

thanks
david jencks

On Dec 20, 2011, at 10:13 AM, David Jencks wrote:

OK, I just committed this stuff, with reference to GERONIMO-6240.

Some more hints....

I can build all the way through with 
MAVEN_OPTS="-XX:MaxPermSize=2048m -Xms2048m -Xmx4096m"

I can start karaf after setting

export JAVA_MAX_MEM=2048m
export JAVA_MAX_PERM_MEM=512m

The car packaging is set up to stop and wait if it gets stuck.  In an earlier version of this you'd get the karaf console and you could use karaf commands to investigate what was going on.  For some reason this isn't working now.  If you get into this situation, you need to kill the maven java process some way.  Usually setting a breakpoint at DependencyManager line 571 will show you a bundle that has a resolution problem that you can then fix.

The problem with the console deploy-type commands I think relates to using the karaf RMIRegistry.  I'm going to modify it so it includes the port as a service property, then we can look for the osgi service and get its port instead of the port gbean attribute.

thanks
david jencks

On Dec 19, 2011, at 9:10 PM, David Jencks wrote:

more not-yet-working inline

On Dec 19, 2011, at 5:08 PM, David Jencks wrote:

I've been spending a lot of time working to rebase geronimo on karaf 3 so we can have a maintainable future and get stuff like osgi 4.3, up to date aries components, and the experimental region support now in karaf.

After a lot of work I have everything except clustering building and after turning off a couple problematic modules the tomcat-javaee6 server starts and the web admin console appears to work at least a little bit.   I'd like a little vacation this year and would like to commit this work first so that others can help with the loose ends if they like.  I'll probably be around to answer questions in any case.

The modules that don't start are:

activemq-broker-blueprint.  The ${X + Y} stuff is not getting evaluated at all.  I don't know if this is an xbean-blueprint problem or an aries blueprint problem or a side effect of running in geronimo.
As a result activemq-ra and tomcat-console-activemq can't be started.

client-deployer.  I think this is a pretty simple gbean name problem but I haven't looked into it.


Here are some of the changes:

-- assemble the server using a combination of karaf assembly from features and kars and geronimo assembly from geronimo plugins.  We now use the same base karaf assembly stuff as the normal default full karaf assembly (except I might have left out the spring feature repository).

-- basic geronimo components such as the kernel, configuration manager, dependency manager, deployer, and service config builder are set up as osgi declarative services so they start without any geronimo configuration.  They are generally configured through config admin as appropriate.  Most of these also have gbean wrappers so they can be accessed through gbean references.

-- "geronimo" is started from a DS component, EmbeddedDaemon.

-- I think I'm using the karaf remote jmx security rather than ours.  The capabilities are similar but not identical.

Some other things that are not working yet:

-- The (gogo) geronimo console commands that work through "remote" gbean proxies don't work AFAIK.  Probably one way to fix this would be to expose some more of the DS components using gbean wrappers, but I haven't looked into this yet.

-- the app client (as well as the client-deployer) is not working yet at all.  We may be able to use command line args to tell the EmbeddedDaemon it's an app client, or possibly not.  We may be able to use a karaf instance to supply different ConfigAdmin settings to e.g. the local attribute manager to convince it it's an app client.  Similarly the separate console-like things presumably won't work either.

-- the EditableConfigurationManager needs to be replaced by a separate component that edits the configuration it gets from the normal configuration manager.  I think this affects some part of the admin console.

--I couldn't get the xml stream 1.2 and jaxb 2.2 to work with the spec jars as bundles.    According to http://servicemix.396122.n5.nabble.com/DISCUSS-Enhance-specs-to-work-better-with-JRE-td5001108.html even if you do get them to work (as we seem to have up to now by not exposing the packages from the framework) that breaks other stuff.  I think we need to investigate the karaf-activator stuff guillaume wrote and adapt our specs to use it.  At the moment I have the framework lying and claiming later versions for the xmlstream and jaxb packages.  I haven't found any documentation for karaf-activator yet.

-- the build uses a lot more memory.  I typically run out of permgen twice during the build with MAVEN_OPTS =  -XX:MaxPermSize=512m -Xms1024m -Xmx2048m

-- startup AFAIK only works as ./bin/karaf -l rather than our geronimo scripts.  Again, I have to increase memory settings for the server to fully start.



I'f there's no strong opposition I'd like to commit this tomorrow.

Many thanks
david jencks


david jencks





--
Thanks!

Regards, Forrest





--
Thanks!

Regards, Forrest




--
Thanks!

Regards, Forrest


Gmane