gmane.comp.java.picocontainer.devel

Re: [picocontainer-dev] nanocontainer-testmodel in Maven Central has invalid checksum

Mauro Talevi — 2012-04-17T07:56:21

It's most likely that JacORB has been a bit careless with the dependency 
management.

The testmodel jar should probably not be transtitive and you can 
excluded from your dependency tree.

On 16/04/2012 22:11, Devin Greene wrote:


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[picocontainer-dev] nanocontainer-testmodel in Maven Central has invalid checksum

Devin Greene — 2012-04-16T20:11:47

I'm not sure if this is the right place to report this or not.

The POM file for nanocontainer-testmodel 1.0 entry in Maven Central has an
invalid SHA1 checksum. I've repeated downloaded the file and checked it, and the
SHA1 checksum of the POM file is incorrect.

This is causing me grief even though I'm not using nanocontainer myself, because
it is a transitive dependency of JacORB (which I am using).

Can this be fixed, or do you know who should be contacted to address this?


http://search.maven.org/#artifactdetails|nanocontainer|nanocontainer-testmodel|1.0|jar




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[picocontainer-dev] A plea for removal of session container for Pico-Web 3

Michael Rimov — 2012-03-15T21:35:48

Paul, et al,

 

I know the session container is convenient.  But frankly, it has problems
that IMO do not make it worthwhile:

 

1.       It's too easy for newbies to cause memory leaks by referencing the
app-level container in their objects.  We don't want to help people hang
themselves.

2.       Forced session creation makes it very easy to "DOS" a public
webserver by simply having a bot check for requests and discard the session
cookie.  New session created each time until the server runs out of memory.
(And yes, I forgot to set session="false" on a jsp home page for a client,
and that's exactly what happened. a bot from the Ukraine repeatedly hit the
same page, and down the server went)

 

Now if I'm misunderstanding the mechanics on point 2, I'm cool with
repentance for posting this :-)  Otherwise, I'd REALLY like to see this
feature removed.

 

Thanks for listening :)

 

 
-Mike

[picocontainer-dev] reflectasm - allegedly faster reflection calls.

Paul Hammant — 2011-12-08T15:26:53

This looked interesting :-

   http://code.google.com/p/reflectasm/

... looks pretty intriguing. Faster it claims.

I did some testing last night and it's only 10% faster than regular
reflection for method invocations, and only if your cache the ASM-made
subclass of "MethodAccess".

There are some flaws too:

   1.   It generates accessors for each method in a class  - you may have
   been interested in only a single method.
   2.   It assumed that there is no method overloading in the class
   3.   Exceptions will pass through (no InvocationTargetException), yet
   are not (and cannot be) concisely listed on the throws clause of the
   var-args invoke method you use.  You have to be aware of the exceptions
   that could be thrown, or catch base Exception (yeesh).

It does one interesting trick. See
http://reflectasm.googlecode.com/svn/trunk/src/com/esotericsoftware/reflectasm/MethodAccess.java

MethodAccess (the class) is in your regular classpath on use, as normal
Java launch semantics.  The classes that ASM generates ALSO purport to be
MethodAccess (same package), but by some defineClass magic in a child
class-loader, are instantiated instead of the real deal.  The Java Compiler
lets you think you are using static method on MethodAccess, but at runtime
you are using a method with the same signature in a different class (with
the same name).

It got me thinking though.

Say, for < at >Inject methods (and constructors, poss fields too)
There could be a QDox build stage that kicks in and makes an invoke class
for each so-annotated method.

In the same way that GMaven allows Java and Groovy to interop in the same
source buildable jar (by generating shims of the Groovy classes for the
Java classes to compile against), some tricks that JetBrains and Eclipse
would buy into would allow a method invocation design that was more first
class than reflection.  For example:

public class Foo {
    < at >Inject
    public void bar(Baz baz) {
    }
}

public static void main(String[] args) {
    Foo instance = new Foo();
    Foo.bar1965ed0b.invoke(instance, new Baz());
}

          // 1965ed0b is a CRC32 hash of 'Baz baz'


PicoContainer, Guice etc could speculatively look for the inner
class bar1965ed0b and use it.  It would still not preserve throws clauses
as Pico/Guice would cast it to a interface to use it for the speed you're
seeking.  It would be in the same jar file of course.  Shame about the
extra bytes - AFAICR the min byte size of an inner class is 178.

Java7's project coin <http://openjdk.java.net/projects/coin/> makes this a
bit moot though perhaps.

- Paul

Re: [picocontainer-dev] Update Maven Resources Plugin Version?

Paul Hammant — 2011-12-03T21:36:42

I tried once, but foolishly upgraded about 15 or so in one go before
running mvn to see the damage.  I'm getting dafter as I get older!

- Paul

On Sat, Dec 3, 2011 at 2:56 PM, Michael Rimov <rimovm-1s3I9JzM0AlPC9TT5Vdp3Q< at >public.gmane.org> wrote:

[picocontainer-dev] Update Maven Resources Plugin Version?

Michael Rimov — 2011-12-03T20:56:29

Hi All,

 

I'm running m2E on indigo, and the maven pom won't validate because
Maven-Eclipse plugin requires a maven-resources-plugin of at least 2.4.
There are several projects in Pico land with a much smaller version #.
Would there be any serious impact to people if I bumped the
maven-resources-plugin version to a recent version?

 

 
-Mike

[picocontainer-dev] JSR 277 future...

Michael Rimov — 2011-11-18T00:52:43

Hi Guys,

 

I started the module project for Pico 3 in the hopes of taking the old
deployer and making it a lot more feature rich for my own needs.  Of course,
one of the things that deployer was also about was showing that you could do
simpler stuff than OSGi.

 

I'm a guy that doesn't get out much, but it seems that ever since Oracle put
off  "project jigsaw" until JDK 8, I haven't seen any activity that tells me
it's ever going to come to fruition.  

 

However, if it is going full steam ahead and I just don't know it yet, it's
not really worth for me to continue ramping up the modules project.

 

So the question is for those of you "in the know".. Do you thnk Project
Jigsaw/JSR 277 is ever going to see the light of day?

 

 
-Mike

[picocontainer-dev] I'm going to push out 2.14.1 with two more bugfixes and the 'volatile' fix of a bug fix ..

Paul Hammant — 2011-11-10T04:08:08

Re: [picocontainer-dev] Commit 5799 Race Condition Fix....

Paul Hammant — 2011-11-08T16:58:30

Yup that wikipedia entry highlights a bug.  Good catch & thanks for
weighing in Pete.

There's another bug-fix that should perhaps make it into a 2.14.1 release -
PICO-382 and PICO-384.  I've looked at the former's testcase and compiled
it for the sake of a test.  I'm somewhat hogtied at the moment for
interactive debugging as JetBrains's haven't given Codehaus a new Intellij
license yet :-(

- Paul

On Mon, Nov 7, 2011 at 8:07 PM, Michael Rimov <rimovm-1s3I9JzM0AlPC9TT5Vdp3Q< at >public.gmane.org> wrote:

RE: [picocontainer-dev] Commit 5799 Race Condition Fix....

Michael Rimov — 2011-11-08T02:07:32

Oh that’s good, I remember when even volatile wasn’t enough and you had to synchronize the whole method…. I don’t miss the days of JDK 1.0 (rofl)

 

However, the variable ‘initialized’ wasn’t declared as volatile, so I’ve done it and checked it in… as I patch pico 3 I’ll go over it and see if there’s more items like that and I’ll get that fixed.

 

Paul:  Sorry I had the name wrong, it’s ‘double-checked locking’, not ‘double-lock checking’  Anyway, if you aren’t familiar with it, Wikipedia’s writeup isn’t too shabby:

http://en.wikipedia.org/wiki/Double-checked_locking

 

When I’m done going through the code, I’ll let you guys know so you can release a 2.14.1 if we don’t get other things fixed when I’m done.

 

                                                                                                                                                -Mike

 

 

From: peter royal [mailto:peter.royal-e+AXbWqSrlAAvxtiuMwx3w< at >public.gmane.org] 
Sent: Monday, November 07, 2011 5:42 PM
To: dev-qxt/k92ZUMzOYGyH7mwfjrEhcVWVsK+1HZ5vskTnxNA< at >public.gmane.org
Subject: Re: [picocontainer-dev] Commit 5799 Race Condition Fix....

 

it's safe in modern vms as long as injectionMembers is declared volatile

 

-pete

Re: [picocontainer-dev] Commit 5799 Race Condition Fix....

peter royal — 2011-11-08T01:42:01

it's safe in modern vms as long as injectionMembers is declared volatile

-pete

Re: [picocontainer-dev] Commit 5799 Race Condition Fix....

Paul Hammant — 2011-11-08T01:31:41

I eliminated the situation I was getting in a production deployment.  I'm
not sure what you mean Mike.

-ph

On Mon, Nov 7, 2011 at 6:43 PM, Michael Rimov <rimovm-1s3I9JzM0AlPC9TT5Vdp3Q< at >public.gmane.org> wrote:

[picocontainer-dev] Commit 5799 Race Condition Fix....

Michael Rimov — 2011-11-08T00:43:08

Paul,

I was looking < at > the diffs....  and this code in Iterative adapter:

       if (injectionMembers == null) {
            synchronized (this) {
                if (injectionMembers == null) {
                    initializeInjectionMembersAndTypeLists();
                }
            }
        }

Isn't that double-check locking and not really solving the race condition?
Or is Boolean assignment exempt from this kind of situation?


-Mike



-----Original Message-----
From: Paul Hammant [mailto:paul-POq8DFUn+ZRAfugRpC6u6w< at >public.gmane.org] 
Sent: Monday, November 07, 2011 11:53 AM
To: dev-qxt/k92ZUMzOYGyH7mwfjrEhcVWVsK+1HZ5vskTnxNA< at >public.gmane.org
Subject: Re: [picocontainer-dev] Release of Pico 2.14

My bad - I've only just done the nexus 'approval'.  Give it four hours or
so.  Meanwhile build from source :

     http://svn.codehaus.org/picocontainer/java/2.x/tags/picocontainer-2.14/
     mvn clean install -DskipTests -Preporting

On Mon, Nov 7, 2011 at 1:28 PM, Simon Brandhof <simon.brandhof-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>
wrote:

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

RE: [picocontainer-dev] Release of Pico 2.14

Michael Rimov — 2011-11-08T00:35:34

It's live now -- you may need to clear your browser cache to see it though
in the directory listings, but 

https://nexus.codehaus.org/content/repositories/public/org/picocontainer/pic
ocontainer/2.14/

Is working now

-Mike

-----Original Message-----
From: Paul Hammant [mailto:paul-POq8DFUn+ZRAfugRpC6u6w< at >public.gmane.org] 
Sent: Monday, November 07, 2011 11:53 AM
To: dev-qxt/k92ZUMzOYGyH7mwfjrEhcVWVsK+1HZ5vskTnxNA< at >public.gmane.org
Subject: Re: [picocontainer-dev] Release of Pico 2.14

My bad - I've only just done the nexus 'approval'.  Give it four hours or
so.  Meanwhile build from source :

     http://svn.codehaus.org/picocontainer/java/2.x/tags/picocontainer-2.14/
     mvn clean install -DskipTests -Preporting

On Mon, Nov 7, 2011 at 1:28 PM, Simon Brandhof <simon.brandhof-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>
wrote:

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Re: [picocontainer-dev] Release of Pico 2.14

Paul Hammant — 2011-11-07T19:52:58

My bad - I've only just done the nexus 'approval'.  Give it four hours
or so.  Meanwhile build from source :

     http://svn.codehaus.org/picocontainer/java/2.x/tags/picocontainer-2.14/
     mvn clean install -DskipTests -Preporting

On Mon, Nov 7, 2011 at 1:28 PM, Simon Brandhof <simon.brandhof-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Re: [picocontainer-dev] Release of Pico 2.14

Simon Brandhof — 2011-11-07T19:28:06

Hi Paul,

Will this release be deployed in Maven repository ?

Thanks


On 7 November 2011 19:04, Paul Hammant <paul-POq8DFUn+ZRAfugRpC6u6w< at >public.gmane.org> wrote:

Re: [picocontainer-dev] Release of Pico 2.14

Paul Hammant — 2011-11-07T18:04:53

Hey Mike.  The answer is I'm not sure.  It's pretty up to date - go
for it:  The stuff that's in the latest release isn't in 3.x / Git
yet.

- Paul

On Mon, Nov 7, 2011 at 10:38 AM, Michael Rimov <rimovm-1s3I9JzM0AlPC9TT5Vdp3Q< at >public.gmane.org> wrote:

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

RE: [picocontainer-dev] Release of Pico 2.14

Michael Rimov — 2011-11-07T16:38:23

Hey Paul,

What is the last change you ported over to Pico 3?

I'll be happy to manually port based on the diffs, but I wanted to make sure
before I started that I wasn't duplicating efforts.

Thx

-Mike

P.S.  Sorry I haven't been very active since May...  got hammered work-wise
and when the options are (a) Pico, (b) A little sleep.... sleep wins :D

-----Original Message-----
From: Paul Hammant [mailto:paul-POq8DFUn+ZRAfugRpC6u6w< at >public.gmane.org] 
Sent: Monday, November 07, 2011 5:58 AM
To: dev
Subject: [picocontainer-dev] Release of Pico 2.14

Hi gang,

I've made a couple of bugfixes, and reworked the exception throwing for
"unsatisfied dependency" situations.  The latter used to be cryptic, but are
now clearer.

- Paul

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[picocontainer-dev] Release of Pico 2.14

Paul Hammant — 2011-11-07T13:57:33

Hi gang,

I've made a couple of bugfixes, and reworked the exception throwing
for "unsatisfied dependency" situations.  The latter used to be
cryptic, but are now clearer.

- Paul

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Re: [picocontainer-dev] Just pushed 2.13.3 for Alex Koval ...

Paul Hammant — 2011-04-12T14:30:34

OK, I'll look in the source for broken links.
https://github.com/picocontainer/picocontainer.github.com

I should also link to the freshmeat project I think.

- Paul

On Tue, Apr 12, 2011 at 8:36 AM, Michael Rimov <rimovm-1s3I9JzM0AlPC9TT5Vdp3Q< at >public.gmane.org>wrote:

RE: [picocontainer-dev] Just pushed 2.13.3 for Alex Koval ...

Michael Rimov — 2011-04-12T13:36:28

Paul,

 

I was about to push a freshmeat announcement out (I've been slackin' in that
area!)  and I noticed that

http://repository.codehaus.org/org/picocontainer is empty?

 

Docs still point there to download.

-Mike

 

From: Paul Hammant [mailto:paul-POq8DFUn+ZRAfugRpC6u6w< at >public.gmane.org] 
Sent: Monday, April 11, 2011 10:41 PM
To: dev
Subject: [picocontainer-dev] Just pushed 2.13.3 for Alex Koval ...

 

.... he's upgrading from 1.3 and needs the constructor.setAccessible(true)
stuff that was previously deleted.

 

- Paul