http://blog.gmane.org/gmane.comp.java.picocontainer.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.java.picocontainer.devel/6432 <pre>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 </pre> Devin Greene 2012-04-16T20:11:47 http://comments.gmane.org/gmane.comp.java.picocontainer.devel/6431 <pre>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 </pre> Michael Rimov 2012-03-15T21:35:48 http://comments.gmane.org/gmane.comp.java.picocontainer.devel/6430 <pre>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 </pre> Paul Hammant 2011-12-08T15:26:53 http://comments.gmane.org/gmane.comp.java.picocontainer.devel/6428 <pre>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 </pre> Michael Rimov 2011-12-03T20:56:29 http://comments.gmane.org/gmane.comp.java.picocontainer.devel/6427 <pre>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 </pre> Michael Rimov 2011-11-18T00:52:43 http://comments.gmane.org/gmane.comp.java.picocontainer.devel/6426 <pre> </pre> Paul Hammant 2011-11-10T04:08:08 http://comments.gmane.org/gmane.comp.java.picocontainer.devel/6421 <pre>Paul, I was looking &lt; at &gt; 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&lt; at &gt;public.gmane.org] Sent: Monday, November 07, 2011 11:53 AM To: dev-qxt/k92ZUMzOYGyH7mwfjrEhcVWVsK+1HZ5vskTnxNA&lt; at &gt;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 &lt;simon.brandhof-Re5JQEeQqe</pre> Michael Rimov 2011-11-08T00:43:08 http://comments.gmane.org/gmane.comp.java.picocontainer.devel/6415 <pre>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 </pre> Paul Hammant 2011-11-07T13:57:33 http://comments.gmane.org/gmane.comp.java.picocontainer.devel/6412 <pre>.... he's upgrading from 1.3 and needs the constructor.setAccessible(true) stuff that was previously deleted. - Paul </pre> Paul Hammant 2011-04-12T05:40:34 http://comments.gmane.org/gmane.comp.java.picocontainer.devel/6411 <pre>Hi Gang, I did some work on the JSR330 module. Principally dumbing it down to be JUnit 3.8.1 rather than JUnit4. It wants to live as an old fashioned test-suite so who am I to argue with it. There are two test classes - neither passes. Both leverage the test suite from JSR330 to show what has been injected incorrectly. - One, ManualInjectionJsr330TestCase, is an attempt to pass the TCK without a container - The other PicoContainerJsr330TestCase attempts the same with a PicoContainer doing the setup Anyway, it should be easy for anyone to jump into, if they feel inclined :) - Paul </pre> Paul Hammant 2011-03-06T22:56:57 http://comments.gmane.org/gmane.comp.java.picocontainer.devel/6410 <pre> </pre> Paul Hammant 2011-03-05T03:36:55 http://comments.gmane.org/gmane.comp.java.picocontainer.devel/6408 <pre>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 </pre> Paul Hammant 2011-02-27T05:35:12 http://comments.gmane.org/gmane.comp.java.picocontainer.devel/6401 <pre>... at least, the for the changes I'd made in the last six months. - Paul </pre> Paul Hammant 2011-02-01T14:13:07 http://comments.gmane.org/gmane.comp.java.picocontainer.devel/6400 <pre>http://picocontainer.org/ now uses a Jekyll based auto-build that Github do for you on commit. Refer http://pages.github.com/ The styling is trying to borrow something from Aslak's http://cukes.info/homepage which is truly excellent IMO. The Pico site follows the same ideas, but is actually highly modified fork of http://claudiob.github.com/ We get site control in plain text "textile" (any many other) documents, and a blogging platform built in. Here's an example of the work I had to do: http://picocontainer.org/web/webwork1.html was effected in a straight forward commit https://github.com/picocontainer/picocontainer.github.com/commit/d97efcc03606a6ff4640b3566884583e322b98e7 The text of the page was cut/paste from rendered HTML source, and put back into a text editor. A few textile commands were added, and links added back, then saved and committed. A Github daemon puts that live one minute later. For those that are interested, over the years we've gone through: 1) Full Confluence site, with exampl</pre> Paul Hammant 2011-01-29T20:34:55 http://comments.gmane.org/gmane.comp.java.picocontainer.devel/6397 <pre>Hi list, Is there any way to use Decorated with 2.x without using Decorating ? Point is, I want to use a certain adapter and a certain Decorator on only a limited set of components I'm registering, and it seems like creating my container with the Decorating factory will have all my components decorated. If org.picocontainer.behaviors.Decorated.Decorator was public, I guess I could do what I want here, but maybe I'm look at it the wrong way, and there's another method I could use ? I'm essentially trying to decorate components, bean-style, based on an existing mechanism (which loads those values of a JCR repository, if you must know) - so while I know where those values come from at registration time, I have no idea what they (add to that the fact that I need to proxy those objects because said values can change over time;)) Thanks for any hint, -g --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_em</pre> Grégory Joseph 2011-01-27T18:18:25 http://comments.gmane.org/gmane.comp.java.picocontainer.devel/6394 <pre>Hey guys, I attached patches to http://jira.codehaus.org/browse/PICO-379 and PICO-380. I know we're all busy with other things, but I just want to ping you guys and check how much hope I should have to get this applied (and released??) soon. Also, I haven't checked 3.0 yet, so I have no idea if those are 2.x-only issues... thoughts ? Cheers, -greg ps: would it be possible to maintain Jira a little closer ? Versions are missing and/or not marked as released, making it difficult to report bugs precisely, or to see what changed in a given release. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email </pre> Grégory Joseph 2011-01-20T19:21:06 http://comments.gmane.org/gmane.comp.java.picocontainer.devel/6391 <pre>.... I plan to folks. That is unless anyone has objections. - Paul </pre> Paul Hammant 2011-01-06T12:12:55 http://comments.gmane.org/gmane.comp.java.picocontainer.devel/6390 <pre>Test case: Reader script = new StringReader("" + "importClass(Packages.org.picocontainer.NameBinding);\n" + "var pico = parent.makeChildContainer() \n" + "pico.addComponent(Packages.org.picocontainer.script.testmodel.A)\n" + "var ca = pico.getComponentAdapter(Packages.org.picocontainer.script.testmodel.A, null);\n" + ""); PicoContainer parent = new PicoBuilder().withLifecycle().withCaching().build(); ContainerBuilder containerBuilder = new JavascriptContainerBuilder(script, getClass().getClassLoader()); PicoContainer pico = buildContainer(containerBuilder, parent, "SOME_SCOPE"); //Failure here Fails with compilation exception since there are more than one getComponentAdapter two-arg calls. Is there a way to cast the null value so rhino knows which method to call, or should I implement something like NameBinding.NULL as an alternative to a null argument? (I'm mainly interested in a Pico </pre> Michael Rimov 2010-12-16T16:32:43 http://comments.gmane.org/gmane.comp.java.picocontainer.devel/6386 <pre>Johann Burkard has made a few quality patch contributions over the last year. I think it would be a good idea at this stage to offer him committership to PicoContainer. Thoughts? - Paul PS - see the latest version of the site :- http://picocontainer.github.com/ - it's getting there !!!! --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email </pre> Paul Hammant 2010-12-06T22:04:25 http://comments.gmane.org/gmane.comp.java.picocontainer.devel/6383 <pre>Hi guys, Pico 2 behavior: AbstractContainerBuilder would automatically start all containers that it created. New Pico 3 behavior I just checked in: Starting behavior has been refactored out into a decorating AutoStartingContainerBuilder. So you get Pico 2 behavior with: ContainerBuilder builder = new AutoStartingContainerBuilder(new GroovyContainer(.....)); I needed it for me because I kept running into situations where parent.makeChildContainer() would cause all sorts of conniptions when both the parent and child were deployed through the container builders; and my "don't change any behavior" fix through the constructor args was __U G L Y__. Let me know if there are better options that you can see. -Mike --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email </pre> Michael Rimov 2010-11-30T13:40:18 http://comments.gmane.org/gmane.comp.java.picocontainer.devel/6380 <pre>I'm inspired by :- http://cukes.info/ and http://sites.google.com/site/cobolunit/ And we now have https://github.com/picocontainer/picocontainer.github.comwhich auto-generates (on commit) into http://picocontainer.github.com/ (the front page is a legacy of the fork operation) whereas http://picocontainer.github.com/caching.html should look more familiar. I'm playing with pygments, liquid, and jekyll - all of which are built in to that toolchain. More later ... - Paul </pre> Paul Hammant 2010-11-24T23:27:31 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.java.picocontainer.devel