Devin Greene | 16 Apr 22:11
Picon

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

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

Michael Rimov | 15 Mar 22:35
Favicon

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

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

 

 

Paul Hammant | 8 Dec 16:26

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

This looked interesting :- 



... 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).

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 makes this a bit moot though perhaps.

- Paul 
Michael Rimov | 3 Dec 21:56
Favicon

[picocontainer-dev] Update Maven Resources Plugin Version?

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

 

Michael Rimov | 18 Nov 01:52
Favicon

[picocontainer-dev] JSR 277 future...

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

Paul Hammant | 10 Nov 05:08

[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 | 7 Nov 14:57

[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

Paul Hammant | 12 Apr 07:40

[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
Paul Hammant | 5 Mar 04:36

[picocontainer-dev] test


Paul Hammant | 27 Feb 06:35

[picocontainer-dev] Release of pico 2.x tomorrow ?

If anyone has any changes that are ready, get 'em in, I'm hoping to push a new release tomorrow :) 


2.13 or whatever.

- Paul
Paul Hammant | 1 Feb 15:13

[picocontainer-dev] merges are complete to the v3 (git) from v2 (svn)

... at least, the for the changes I'd made in the last six months.


- Paul

Gmane