Re: [weld-dev] non-visable classes and constructors
by Gavin King
> The spec says:
>
>
> "A top-level Java class is a managed bean if it is defined to be a
> managed bean by any other Java EE specification, or if it meets all of
> the following conditions:
> • It is not a non-static inner class.
> • It is a concrete class, or is annotated @Decorator.
> ...
> • It has an appropriate constructor—either:
> • the class has a constructor with no parameters, or
> • the class declares a constructor annotated @Inject.
>
> All Java classes that meet these conditions are managed beans and thus
> no special declaration is required to define a man- aged bean."
>
> Which part of the word "all" do you not understand? ;-)
>
> But more importantly, there is a very good usecase for allowing this
> case. I might be using an interface at the injection point, and hiding
> the actual implementation of the client by declaring the bean class
> package private. This is just like having a factory method defined
> within the package, so I'm not "breaking" any normal Java behavior
> here.
>
> Now, look, I'm slightly sympathetic to the idea that we could have
> chosen to say that bean constructors must not be private private, and
> that if the constructor with no parameters is private, then the class
> is not a bean. That would not be a completely unreasonable behavior
> (it doesn't necessarily follow from first principles, but you could do
> a bit of guessing about user intent and say that it's reasonable). But
> we didn't say that. We said something else. And the spec is now final.
> So for portability, we all have to comply with that.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
16 years
Initialising newly registered beans
by Peter Royle
Hi,
I've got this extension which I'm using to explicitly register all of the managed beans used by Weld Java SE:
public class WeldSEBeanRegistrant implements Extension
{
private final ClassTransformer transformer = new ClassTransformer(new TypeStore());
public void registerWeldSEBeans(@Observes AfterBeanDiscovery event, BeanManagerImpl beanManager)
{
addBean(ShutdownManager.class, beanManager, event);
addBean(ParametersFactory.class, beanManager, event);
}
private void addBean(final Class<?> klass, BeanManagerImpl beanManager, AfterBeanDiscovery event)
{
WeldClass<?> weldClass = WeldClassImpl.of(klass, transformer);
ManagedBean<?> bean = ManagedBean.of(weldClass, beanManager);
event.addBean(bean);
bean.initialize( ___environment___);
}
}
My question is: where should I get the value for ___environment___ from? Is there common idiom for this?
I feel like if I could get access to the 'parent' variable at WeldBootstrap:199 I could call it.getBeanDeployer().getEnvironment() ... but I could be way off!
Cheers,
Pete.
16 years
Re: [weld-dev] Initialising newly registered beans
by Matt Drees
Oops, I forgot to reply-all:
On Mon, Nov 30, 2009 at 12:45 AM, Matt Drees <matt.drees(a)gmail.com> wrote:
>
>
> On Sun, Nov 29, 2009 at 6:21 PM, Peter Royle <
> howardmoon(a)screamingcoder.com> wrote:
>
>> Hi,
>>
>> I've got this extension which I'm using to explicitly register all of the
>> managed beans used by Weld Java SE:
>>
>> public class WeldSEBeanRegistrant implements Extension
>> {
>>
>> private final ClassTransformer transformer = new ClassTransformer(new
>> TypeStore());
>>
>> public void registerWeldSEBeans(@Observes AfterBeanDiscovery event,
>> BeanManagerImpl beanManager)
>> {
>> addBean(ShutdownManager.class, beanManager, event);
>> addBean(ParametersFactory.class, beanManager, event);
>> }
>>
>> private void addBean(final Class<?> klass, BeanManagerImpl beanManager,
>> AfterBeanDiscovery event)
>> {
>> WeldClass<?> weldClass = WeldClassImpl.of(klass, transformer);
>> ManagedBean<?> bean = ManagedBean.of(weldClass, beanManager);
>> event.addBean(bean);
>> bean.initialize( ___environment___);
>> }
>> }
>>
>>
> Well, I believe the portable way to do this is:
>
>
>
> private void addBean(final Class<?> klass, BeanManagerImpl beanManager,
> AfterBeanDiscovery event)
> {
> Bean newBean = createBean(beanManager.createInjectionTarget(klass),
> beanManager.createAnnotatedType(klass));
> beanManager.addBean(newBean);
> }
>
> where createBean() can either manually create an implementation of Bean
> that delegates appropriately to the InjectionTarget and AnnotatedType, or
> you can use BeanImpl from the weld-extensions project (you'd have to throw
> in an extraneous Reannotated() call, but no biggie).
> I think if you do it this way, you won't have to worry about Weld's
> ManagedBean.initialize().
>
> Haven't tried it though.
>
> -Matt
>
>
(Also, beanManager.createInjectionTarget takes should take the created
AnnotatedType, not klass)
>
>
>>
>> Cheers,
>>
>> Pete.
>>
>>
>>
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>
>
>
16 years
rationale for JTA/JPA questions - trying to add JPA support to archetypes
by Boscarine, Steven
I honestly can't tell your tone in your responses as to whether or not you're getting annoyed with these questions on this list and the forums. I am not trying to troll on Spring's behalf and am sincerly trying to help get JSF 2 and CDI adopted in my organization, local user groups, and promote it to those who are willing to read what I'm writing both on your site and what I am trying to write about on our blog. That's why I am working with Dan and Pete on the archetypes.
The whole motivation for the asking about JPA in the first place is because I wanted to put JPA support in the Weld archetypes and documentation. http://seamframework.org/Documentation/WeldQuickstartForMavenUsers
If tomcat users need to use EJBLite, I'm happy to put that in the documentation.
I am just asking because I wasn't aware of what Dan was referring to when he said "Yes, if I spend half the day searching the web to find a tutorial that actually works, maybe I can "upgrade" these containers to support JTA, but that's a PITA." It was a sincere question because my experience was much different.
I fully understand that Tomcat is limited compared to a JEE6. However, if there are reasonable hoops the Tomcat users can jump through to get basic functionality, such as JPA or basic transactions, I think it will be very beneficial to document them for the sake of CDI adoption. I am even happy to personally document polite arguments as to why it is to their benefit to switch to a "real container."
I think it is quite reasonable to expect users to want to try out a new technology, such as JEE6 features like CDI, on their existing infrastructure and persuade their stakeholders to schedule an upgrade to a proper JEE6 container once their prototypes are successful and JBoss 6.0 is out of beta and has passed their internal tests.
________________________________________
From: Gavin King [gavin.king(a)gmail.com]
Sent: Tuesday, November 24, 2009 7:45 PM
To: Boscarine, Steven
Cc: Dan Allen; Gurkan Erdogdu; Weld-Dev
Subject: Re: [weld-dev] persistence and transactions outside Java EE
On Tue, Nov 24, 2009 at 6:35 PM, Boscarine, Steven
<Steven.Boscarine(a)childrens.harvard.edu> wrote:
> How is the UserTransaction you're mentioning different than the one Spring provides?
> http://static.springsource.org/spring/docs/3.0.x/spring-framework-referen...
Well, here's the difference.
The JTA UserTransaction is defined by the JTA specification, and is
supported by all real Java transaction managers. It's an abstraction
that can accommodate just about any kind of transactional resource you
can think of. It works perfectly with JDBC, JCA, JPA, Hibernate, JDO,
etc.
The Spring transaction manager is a totally proprietary API that ties
your application to Spring, and provides an abstraction of ... other
abstractions. It's a totally bogus, superfluous layer that provides no
additional resource independence, nor additional high-level semantics,
than what is already provided by JTA.
If I wanted to continue making the world a better place by following
in the footsteps of Spring, I would create a new transaction
abstraction called WeldTransaction, which abstracts your application
away from the underlying Spring or JTA transaction. Of course, then
you would probably want to write your own transaction manager to
abstract away from your choice of WeldTransaction, Spring or JTA for
transaction management. This is pretty easy to do, since all these
interfaces have the same three methods: begin(), commit() and
rollback(). If you do this, you might want to consider contributing
your work back to the Spring framework, so that all Spring users can
benefit from your abstraction of our abstraction of their abstraction
of JTA.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
16 years
GIT
by Pete Muir
A quick item we discussed at the f2f meeting was whether to switch to
GIT for our SCM, rather than SVN.
This would give us a IMO a system well suited to our distribued dev
model, it would also make it much easier for others to sandbox PEs and
then contribute them back to us.
The proposal is to use Github to host.
The team members at devoxx were in favour, but what do others think?
Pete
--
Pete Muir
http://in.relation.to/Bloggers/Pete
16 years
Supporting namespaces in Java EE config files (non-portable feature for JBoss AS)
by Pete Muir
Hi Jason,
Something that came up during our Seam team meeting was the issue of config files again. We wanted to investigate again why we can't put namespaced elements into existing java ee config files such as application.xml, ejb-jar.xml, web.xml, but instead have to provide our own... Of course, this is non portable, but it would make life easier for users in our opinion.
Previously we have heard that this would cause us to fail the TCK, but given that this code would never run in the EE TCK, I can't see how.
Any ideas?
Pete
16 years
Re: [weld-dev] [seam-dev] First cab off the rank!
by Gavin King
On Sun, Nov 29, 2009 at 10:39 PM, Gavin King <gavin.king(a)gmail.com> wrote:
> Yes, you're right. So you would need to implement the annotation @interface.
>
> On Sun, Nov 29, 2009 at 10:27 PM, Stuart Douglas
> <stuart(a)baileyroberts.com.au> wrote:
>> What about for @NonBinding members? Won't implementations need to perform their own equality check if there are non binding members?
>>
>> Stuart
>>
>> ________________________________________
>> From: Gavin King [gavin.king(a)gmail.com]
>> Sent: Monday, 30 November 2009 1:22 PM
>> To: Shane Bryzak
>> Cc: Stuart Douglas; seam-dev(a)lists.jboss.org
>> Subject: Re: [seam-dev] First cab off the rank!
>>
>> Yeah. Probably you could just stick the members in an array. You
>> probably don't need to actually implement the annotation interface.
>> You would only need to implement Annotation.
>>
>> Well, the spec does not say explicitly that this would work, but it
>> seems fairly safe.
>>
>> Sent from my iPhone
>>
>> On Nov 29, 2009, at 9:07 PM, Shane Bryzak <sbryzak(a)redhat.com> wrote:
>>
>>> Good point - isn't this simply a case though of implementing the
>>> equals() and hashCode() methods and checking that the members are
>>> equal,
>>> i.e. the same way that AnnotationLiteral does it?
>>>
>>> On 30/11/09 06:36, Stuart Douglas wrote:
>>>> Does it still work when the annotation has members? That was why I
>>>> needed the javassist.
>>>>
>>>> Stuart
>>>>
>>>> ________________________________________
>>>> From: seam-dev-bounces(a)lists.jboss.org [seam-dev-
>>>> bounces(a)lists.jboss.org] On Behalf Of Shane Bryzak
>>>> [sbryzak(a)redhat.com]
>>>> Sent: Monday, 30 November 2009 5:34 AM
>>>> To: Gavin King
>>>> Cc: seam-dev(a)lists.jboss.org
>>>> Subject: Re: [seam-dev] First cab off the rank!
>>>>
>>>> Nope, just wrote my own impl of Annotation which I could then pass
>>>> into
>>>> BeanManager.getBeans().
>>>>
>>>> On 30/11/09 04:32, Gavin King wrote:
>>>>
>>>>> You used a jdk dynamicproxy? Probably a better idea.
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Nov 29, 2009, at 1:01 PM, Shane Bryzak<sbryzak(a)redhat.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>>> Done, although I didn't need to use Javassist. ;)
>>>>>>
>>>>>> On 30/11/09 02:38, Gavin King wrote:
>>>>>>
>>>>>>> Stuart has some code to do this using javassist.
>>>>>>>
>>>>>>> On Sun, Nov 29, 2009 at 2:00 AM, Shane Bryzak<sbryzak(a)redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Almost got this working, however I need to be able to
>>>>>>>> reflectively
>>>>>>>> create an
>>>>>>>> AnnotationLiteral, given a String containing the fully qualified
>>>>>>>> name of the
>>>>>>>> qualifier. Anyone done this before?
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>> _______________________________________________
>>>> seam-dev mailing list
>>>> seam-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>>>
>>>
>>> _______________________________________________
>>> seam-dev mailing list
>>> seam-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>
>
>
> --
> Gavin King
> gavin.king(a)gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
>
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
16 years
Can anyone point me to info on getting a DB Connection in JBoss 6.0?
by Steven Boscarine
Hello All,
How do I get a JPA connection in JEE6? I have never actually used JPA
without Spring and wanted to learn the recommended way. Is there a
tutorial or example, perhaps from JEE5 or Seam, I should follow? Since
I learned from a thread yesterday that @PersistenceContext is no longer
recommended, I thought I'd ask the group.
I am working on a sample application to test the JEE archetypes, so I
wanted it to use best practices. The code has a good chance of
appearing in documentation or the actual archetypes. I am using JBoss
6.0.0.M1 as my container.
Thanks,
Steven
16 years
Re: [weld-dev] SQL framework proof of concept
by Arbi Sookazian
Marcus, yep, this is basically exactly what I did. Now I need to spend some
more time with the API and testing, etc. And unfortunately, today is not a
good day... So thx for the zip offer but I don't think I'll need it for
now. Eventually I'd like to run some load tests to compare performance vs.
iBATIS and Spring JDBC equivalents. I'll need to come up with a
plan/roadmap for this sub-project first and then I'll post that on this
list.
On Thu, Nov 26, 2009 at 12:12 AM, Marcus Smedman <marcus(a)smedman.org> wrote:
> Hi Arbi,
>
>
>
> Not sure if this is what you where referring to, but I got it up and
> running by doing this:
>
>
>
> 1. Create an Eclipse project and add the source from seam-sql.zip
>
> 2. Download weld from http://seamframework.org/Download
>
> 3. Unpack and add the following libs to the project:
>
> * <weld-x.y.z>\artifacts\weld\weld-se.jar
>
> * <weld-x.y.z>\artifacts\weld\weld-servlet.jar
>
> 4. Add a hsql jdbc driver to the project (from
> http://sourceforge.net/projects/hsqldb/files/ or
> <jboss-seam-x.y.z>\lib\hsqldb.jar)
>
> 5. Uncomment the eg.Main.main method and execute it. Generates the
> following output:
>
>
>
> create table users (name varchar not null, username varchar not null
> primary key, password varchar not null)
>
> insert into users (name, username, password) values (?, ?, ?)
>
> update users set name=?, password=? where username=?
>
> select u.name as n from users as u where (u.username=? and
> u.password=?)
>
> Gavin King
>
>
>
> I have an Eclipse proj packed up in a zip if you’d like it (4MB).
>
>
>
> Regards
>
> Marcus
>
>
>
>
>
>
>
> *From:* weld-dev-bounces(a)lists.jboss.org [mailto:
> weld-dev-bounces(a)lists.jboss.org] *On Behalf Of *Arbi Sookazian
> *Sent:* den 26 november 2009 08:41
> *To:* Gavin King
> *Cc:* Weld-Dev
> *Subject:* Re: [weld-dev] SQL framework proof of concept
>
>
>
> I'm interested. Plz provide instructions on how to build/deploy so I can
> test it out (it's getting late so I haven't even opened the project in
> Eclipse yet). I noticed that the public static void main() in Main class is
> commented out. Is it safe to assume that this is basically a Weld SE app
> (or soon to be Seam3) to test with? thx.
>
> On Wed, Nov 25, 2009 at 11:02 PM, Gavin King <gavin.king(a)gmail.com> wrote:
>
> Here's a proof-of concept for the typesafe SQL framework. There's lots
> of stuff missing, but I can already do basic queries, inserts and
> updates. Anyone want to take over from here?
>
> --
> Gavin King
> gavin.king(a)gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
>
> _______________________________________________
> weld-dev mailing list
> weld-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>
>
>
16 years
