Re: Wicket and JEE6

2010-07-31 Thread Erik Brakkee
It appears that I ran into an existing Glassfish V3 issue. The same issue
occurs with passivation of regular EJBs that have an entitymanager injected.

See https://glassfish.dev.java.net/issues/show_bug.cgi?id=11356


Re: Wicket and JEE6

2010-07-30 Thread Erik Brakkee
I have found an elegant solution to the serialization problem.
Basically, in the ComponentInstantiationListener that perform injection, I
am also attaching a new InjectionBehavior. The injection behavior has a
private transient boolean field indicating whether injections are up to
date. Upon serialization/deserialization of a component, this field is reset
to false because it is transient. As a result, I can detect in the
beforeRender() method of the behavior whether I need to do injection.

The code of the component instantiationlistener is now as follows:

@Override
public void onInstantiation(Component aComponent) {
injector.inject(aComponent);
aComponent.add(new InjectionBehavior());
}

With the InjectionBahavior defined as follows:

public class InjectionBehavior extends AbstractBehavior {

private transient boolean injectionUptodate;

public InjectionBehavior() {
injectionUptodate = true;
}

@Override
public void beforeRender(Component aComponent) {
if (!injectionUptodate) {
InjectorBuilder.getInjector().inject(aComponent);
injectionUptodate = true;
}
}
}

This solution prevents unnecessary injection. This is required because
injection is expensive. For a simple class with only one injection I
measured only 1400 injections per second (I understand the weld project is
working on improving performance at the moment).


Another part of the solution is to be able to deal with detachable models
that need to keep a reference to an entity manager. The problem is that
these detachable models are also serialized/deserialized. For this I am
using a similar trick now to create a dynamic proxy of an entity manager
that delegates to a dynamically looked up version of the entity manager. The
lookup is done by creating a dummy object with a @persistenceContet in it
and using CDI to inject/obtain the entity manager. Here similarly, the
lookup caches the entity manager as a transient reference so it knows when
to recompute the entity manager.

The object that does this lookup is in fact a managed bean with a producer
method annoted with @Produces @ApplicationDatabase and @PersistenceContext:

public class EntityManagerLookup implements Lookup {

private static class EmHolder {
@PersistenceContext
private EntityManager em;

public EntityManager getEm() {
return em;
}
}

private transient EntityManager em;

@Override
public Object lookup() throws Exception {
if (em == null) {
EmHolder holder = new EmHolder();
InjectorBuilder.getInjector().inject(holder);
em = holder.getEm();
}
return em;
}

@Produces
@ApplicationDatabase
@PersistenceContext
public EntityManager getDefaultEntityManager() {
LookupProxyFactoryEntityManager factory = new
LookupProxyFactoryEntityManager(
EntityManager.class, new EntityManagerLookup());
return factory.getProxy();
}

}

Using this method, I can inject this serialization-safe entitymanager into
any object using

@Inject @ApplicationDatabase EntityManager entityManager;

So, in fact, I have a two-part solution. First of all it is robust in the
sense that @PersistenceContext still works. Second, I can also use a custom
injection to obtain serialization safe entity managers. When the entity
manager is obtained using the custom method however, problems can still
exist with for instance application scoped objects which also appear to be
serialized (this is in fact wrong as the objects will no longer be
application scoped because several copies are created).

A consequence of this solution is that all injected dependencies should be
declared as transient because this is more efficient.

The code for this can be found at http://utils.wamblee.org (wicket/inject,
support/inject, and support/cdi).


Re: Wicket and JEE6

2010-07-29 Thread Erik Brakkee
I have done a lot of experimentation at the moment and I am using CDI
dependency injection now for a simple wicket project. It is based on the
code at utils.wamblee.org (wicket/inject).

The issue I am running into is the following. I am creating a detachable
entity object which is simply a detachable model that safes the primary key
in onDetach() + sets the object to null.
It loads the object from persistent storage using entityManager.find(class,
key) in the get() method (if not yet initialized).

The detachable model is constructed using an entity manager obtained using
CDI. However, in the following scenario, things go wrong: (1) edit an entity
in a form, (2) click ok, (3) browser back.

What happens is that I get a NullPointerException in EntityManagerWrapper on
line 314 on glassfish v3. What is actually happening here is that the
detachable model is being serialized but the EntityManagerWrapper (the
contextual that delegates to the actual entitymanager to use) has transient
fields which become null after deserialization. The EntityManagerWrapper is
declared Serializable but in fact it isn't.

Now, I have to do two things. First I have to report an issue on glassfish
v3. I think the entity manager wrapper should be truly serializable and not
just declared serializable.  Second, I need to work around this problem. The
solution I am thinking of is to use a simple utility that provides a truly
serializable entity manager that delegates to an entity manager obtained
using CDI. That would solve the problem with the detachable.

However, there is one more issue which is the injection setup in the
application. I still need the injection at component instantiation to allow
use of injected objects in the constructor. But I still have a question
whether it would be required to also use a IComponentOnBeforeRenderListener
to do an additional injection in the onBeforeRender() method. The only
reason I would need to do this is when pages in wicket are serialized as
well. Do I need to take page serialization into account? Is there also a
callback in wicket to listen for component serialization and
deserialization?


Re: Wicket and JEE6

2010-07-29 Thread Erik Brakkee
On Thu, Jul 29, 2010 at 9:54 PM, Erik Brakkee erik.brak...@gmail.comwrote:

  Is there also a callback in wicket to listen for component serialization
 and deserialization?


Googling for this it also seems possible to use an aspectj pointcut to do
injection at deserialization.


Re: Wicket and JEE6

2010-07-29 Thread James Carman
The problem with using the AspectJ-injected references occurs when you
pass your reference to another class (such as a model, for instance).
That class may not be instrumented via AspectJ to handle the
serialization/deserialization properly for that reference.  So, it
will fail.


On Thu, Jul 29, 2010 at 4:14 PM, Erik Brakkee erik.brak...@gmail.com wrote:
 On Thu, Jul 29, 2010 at 9:54 PM, Erik Brakkee erik.brak...@gmail.comwrote:

  Is there also a callback in wicket to listen for component serialization
 and deserialization?


 Googling for this it also seems possible to use an aspectj pointcut to do
 injection at deserialization.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket and JEE6

2010-07-29 Thread Erik Brakkee
On Thu, Jul 29, 2010 at 10:18 PM, James Carman
ja...@carmanconsulting.comwrote:

 The problem with using the AspectJ-injected references occurs when you
 pass your reference to another class (such as a model, for instance).
 That class may not be instrumented via AspectJ to handle the
 serialization/deserialization properly for that reference.  So, it
 will fail.

 I also think it is a dodgy approach with aspect J and that it's best to
avoid it. Also, because it involves additional configuration and more
complexity.

The simplest solution appears to be to inject using the onBeforeRender
listener. The disadvantage is however that I will be doing this injection
too many times (every construction and onBeforeRender).


wicket an JEE6 (web.xml not mandatory)

2010-04-12 Thread moèz ben rhouma
http://www.jroller.com/ouertani/entry/tips_1_wicket_and_jee


Re: Wicket and JEE6

2010-04-12 Thread Erik Brakkee
On Mon, Apr 12, 2010 at 12:12 AM, James Carman jcar...@carmanconsulting.com
 wrote:

 I would imagine that most implementations would cache their injectors
 (it's part of the BeanT)



I was triggered by the remark in the WeldCOmponentInstantiationListener
which says 'TODO Cache the NonContextual'

Also, the NonContextual implementation itself mentions this

  'Store the injection target. The CDI spec doesn't require an
implementation to cache it, so we do'

Therefore, it is probably safer to do the caching ourselves hen to rely on
caching by the beanmanager.


Re: Wicket and JEE6

2010-04-11 Thread Erik Brakkee
Just have a look at https://wamblee.org/svn/public/wicket-cdi
The main thing I did was to make the injection and caching stuff completely
independent of wicket and I made some arrangements to still allow unit tests
where you can inject different things from the defaults.

In particular, I think you can incorporate the InjectorCache in your design
and it would also be good to make the injection support independent of
wicket. Basically, the org.wamblee.cdi package tries to provide a simple and
efficient injection api (bean manager api is too general and too verbose for
most purposes)


Re: Wicket and JEE6

2010-04-11 Thread James Carman
I would imagine that most implementations would cache their injectors
(it's part of the BeanT)

On Sun, Apr 11, 2010 at 4:30 PM, Erik Brakkee erik.brak...@gmail.com wrote:
 Just have a look at https://wamblee.org/svn/public/wicket-cdi
 The main thing I did was to make the injection and caching stuff completely
 independent of wicket and I made some arrangements to still allow unit tests
 where you can inject different things from the defaults.

 In particular, I think you can incorporate the InjectorCache in your design
 and it would also be good to make the injection support independent of
 wicket. Basically, the org.wamblee.cdi package tries to provide a simple and
 efficient injection api (bean manager api is too general and too verbose for
 most purposes)


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket and JEE6

2010-04-10 Thread Erik Brakkee
On Mon, Apr 5, 2010 at 11:58 PM, James Carman
jcar...@carmanconsulting.comwrote:


 What I'll do is set it up in wicketstuff.  That way others can
 contribute/maintain it too.  I've got permission already, so I can put
 it up there sometime this evening.


Do you have a location already for the source? I still think that wicket
core would be a better place since wicket-spring and wicket-guice are also
already there.

Meanwhile I also did some refactoring already and implemented caching Not
much is left of the original code, but I think it is simpler the way I have
it now.  A side effect is that I also have a simple Injector class that can
be used to perform injection into any class. Almost all code I have a is
wicket-independent and the ComponentInstantiationListener is basically a
one-liner now.


Re: Wicket and JEE6

2010-04-10 Thread James Carman
My implementation is available at:

http://svn.carmanconsulting.com/public/wicket-cdi/trunk/

The CdiPlugin class has an inject() method that can be used to inject
anything, also.

On Sat, Apr 10, 2010 at 5:11 PM, Erik Brakkee erik.brak...@gmail.com wrote:
 On Mon, Apr 5, 2010 at 11:58 PM, James Carman
 jcar...@carmanconsulting.comwrote:


 What I'll do is set it up in wicketstuff.  That way others can
 contribute/maintain it too.  I've got permission already, so I can put
 it up there sometime this evening.


 Do you have a location already for the source? I still think that wicket
 core would be a better place since wicket-spring and wicket-guice are also
 already there.

 Meanwhile I also did some refactoring already and implemented caching Not
 much is left of the original code, but I think it is simpler the way I have
 it now.  A side effect is that I also have a simple Injector class that can
 be used to perform injection into any class. Almost all code I have a is
 wicket-independent and the ComponentInstantiationListener is basically a
 one-liner now.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket and JEE6

2010-04-05 Thread Erik Brakkee
On Wed, Mar 31, 2010 at 5:05 AM, Iskandar Salim locrianm...@gmail.comwrote:




 Olivier Bourgeois-2 wrote:
 
  ...
  everything is simple unmanaged POJOs except for your classes extending
  WebPage which are managed
 

 Not to be picky but a minor correction :)
 everything is simple unmanaged POJOs except for your classes extending
 [Component] which are managed



I wonder what the use would be for the request, session, and conversation
scopes in wicket since these are already managed expiicitly in wicket. At
least, I wouldn't see a great need for such scopemanagement by the
container. It would be nice however if CDI could be used to inject EJBs,
resources, and OSGI services into pages.

--
 View this message in context:
 http://old.nabble.com/Wicket-and-JEE6-tp28045129p28091022.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: Wicket and JEE6

2010-04-05 Thread Erik Brakkee

 I wonder what the use would be for the request, session, and conversation
 scopes in wicket since these are already managed expiicitly in wicket. At
 least, I wouldn't see a great need for such scopemanagement by the
 container. It would be nice however if CDI could be used to inject EJBs,
 resources, and OSGI services into pages.



Sorry for the mail bombing but just got @EJB injection to work based on the
weld-wicket integration. With this setup the only thing I am missing is
probably the long-lived convesations support, but that is not essential for
me. Essential is the link to ejbs and container resources and the converged
container support in Java EE6 which will simplify a lot.

The main trick is to register only the component instantiation listener from
weld-wicket in the application class.

class WicketApplication extends WebApplication {

   private NonContextualWeldComponentInstantiationListener
weldComponentInstantiationListener;

/**
 * Constructor
 */
public WicketApplication() {
// Empty.
}

@Override
protected void init() {
BeanManager mgr = BeanManagerLookup.getBeanManager();
System.out.println(BeanManager ' + mgr + ');
this.weldComponentInstantiationListener = new
NonContextualWeldComponentInstantiationListener(BeanManagerLookup.getBeanManager(),
WeldComponentInstantiationListener.class);

addComponentInstantiationListener(weldComponentInstantiationListener.newInstance().produce().inject().get());
}
...
}


Next is simply the use of @EJB in a regular page object.

This works without having to patch the application server.


Re: Wicket and JEE6

2010-04-05 Thread James Carman
Did you not look at what I put together?  I've already got all the
injection stuff (and conversations) working and I've got example
applications illustrating it.

On Mon, Apr 5, 2010 at 3:47 PM, Erik Brakkee erik.brak...@gmail.com wrote:

 I wonder what the use would be for the request, session, and conversation
 scopes in wicket since these are already managed expiicitly in wicket. At
 least, I wouldn't see a great need for such scopemanagement by the
 container. It would be nice however if CDI could be used to inject EJBs,
 resources, and OSGI services into pages.



 Sorry for the mail bombing but just got @EJB injection to work based on the
 weld-wicket integration. With this setup the only thing I am missing is
 probably the long-lived convesations support, but that is not essential for
 me. Essential is the link to ejbs and container resources and the converged
 container support in Java EE6 which will simplify a lot.

 The main trick is to register only the component instantiation listener from
 weld-wicket in the application class.

 class WicketApplication extends WebApplication {

   private NonContextualWeldComponentInstantiationListener
 weldComponentInstantiationListener;

    /**
     * Constructor
     */
    public WicketApplication() {
        // Empty.
    }

   �...@override
    protected void init() {
        BeanManager mgr = BeanManagerLookup.getBeanManager();
        System.out.println(BeanManager ' + mgr + ');
        this.weldComponentInstantiationListener = new
 NonContextualWeldComponentInstantiationListener(BeanManagerLookup.getBeanManager(),
 WeldComponentInstantiationListener.class);

 addComponentInstantiationListener(weldComponentInstantiationListener.newInstance().produce().inject().get());
    }
    ...
 }


 Next is simply the use of @EJB in a regular page object.

 This works without having to patch the application server.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket and JEE6

2010-04-05 Thread Erik Brakkee
On Mon, Apr 5, 2010 at 9:54 PM, James Carman
jcar...@carmanconsulting.comwrote:

 Did you not look at what I put together?  I've already got all the
 injection stuff (and conversations) working and I've got example
 applications illustrating it.


I tried to look at it but couldn't access the subversion repo because of
timeouts. Atter looking at the code of weld-wicket and seeing that it was
just a small amount of code, it was relatively easy to figure out what is
was doing and disable the long-lived conversations support.

The URL I am trying is:
http://svn.carmanconsulting.com/public/wicket-cdi/trunk
Can you make sure the URL is working again? I will then have a look at it.
The aim would be for an implementation that is completely independent of
weld, i.e. does not use any weld core classes and only uses standard CDI
APIs and wicket APIs. (to avoid the problem of having to patch the
application server).


Re: Wicket and JEE6

2010-04-05 Thread James Carman
It's apparently down again.  That's what I get for hosting my server
at my in-law's house.  Cheaper isn't necessarily better.  If you want,
I can email you the code.

On Mon, Apr 5, 2010 at 4:32 PM, Erik Brakkee erik.brak...@gmail.com wrote:
 On Mon, Apr 5, 2010 at 9:54 PM, James Carman
 jcar...@carmanconsulting.comwrote:

 Did you not look at what I put together?  I've already got all the
 injection stuff (and conversations) working and I've got example
 applications illustrating it.


 I tried to look at it but couldn't access the subversion repo because of
 timeouts. Atter looking at the code of weld-wicket and seeing that it was
 just a small amount of code, it was relatively easy to figure out what is
 was doing and disable the long-lived conversations support.

 The URL I am trying is:
 http://svn.carmanconsulting.com/public/wicket-cdi/trunk
 Can you make sure the URL is working again? I will then have a look at it.
 The aim would be for an implementation that is completely independent of
 weld, i.e. does not use any weld core classes and only uses standard CDI
 APIs and wicket APIs. (to avoid the problem of having to patch the
 application server).


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket and JEE6

2010-04-05 Thread Erik Brakkee
On Mon, Apr 5, 2010 at 10:37 PM, James Carman
jcar...@carmanconsulting.comwrote:

 It's apparently down again.  That's what I get for hosting my server
 at my in-law's house.  Cheaper isn't necessarily better.  If you want,
 I can email you the code.


You can mail the code to me.  If it's not too much code, you can also mail
it to the list I guess.

I think in general, the code should become part of a wicket-cdi project just
like wicket-spring and wicket-guice already are. I think the wicket
community is probably a better place to maintain this then the weld project.
This is because the code could use internal wicket APIs which are more prone
to change than the CDI APIs which is a standard. So we would catch problems
in the implementation much earlier. It feels a bit like stealing but I am in
any case really grateful for the work done by the weld project. This is
surely going to save a lot of people some time because standard Java EE
capabilities can be used in wicket.


Re: Wicket and JEE6

2010-04-05 Thread James Carman
On Mon, Apr 5, 2010 at 5:27 PM, Erik Brakkee erik.brak...@gmail.com wrote:
 I think in general, the code should become part of a wicket-cdi project just
 like wicket-spring and wicket-guice already are. I think the wicket
 community is probably a better place to maintain this then the weld project.
 This is because the code could use internal wicket APIs which are more prone
 to change than the CDI APIs which is a standard. So we would catch problems
 in the implementation much earlier. It feels a bit like stealing but I am in
 any case really grateful for the work done by the weld project. This is
 surely going to save a lot of people some time because standard Java EE
 capabilities can be used in wicket.


What I'll do is set it up in wicketstuff.  That way others can
contribute/maintain it too.  I've got permission already, so I can put
it up there sometime this evening.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket and JEE6

2010-03-31 Thread James Carman
 in my patch to
   fix
  one
   of the issues, but we're still hammering out another.
  
   Thanks,
  
   James
  
   On Tue, Mar 30, 2010 at 7:05 AM, Cemal Bayramoglu 
   jweekend_for...@cabouge.com wrote:
  
   Olivier,
  
   I got Jame's stuff [1] up and running (thanks James) with just a few
   small changes to the POMs - maybe he has stuff already in his local
   Maven repo that is no longer on the main public repos) working with
   little effort.
  
   If you'd like to make (and maintain ;-) an archetype out of those
   (based on Apache implementations), or a Galssfish based one,  we
   would
   be happy to include those on our LegUp page [2][3].
  
   Regards - Cemal
   jWeekend
   OO  Java Technologies, Wicket
   Consulting, Development, Training
   http://jWeekend.com
  
   [1] http://svn.carmanconsulting.com/public/wicket-cdi/trunk
   [2] http://jweekend.com/dev/LegUp
   [3] http://code.google.com/p/legup/
  
  
   On 30 March 2010 10:24, Olivier Bourgeois
   olivier.bourgeois@gmail.com wrote:
I do also think that it's because Wicket is not a managed
framework :
everything is simple unmanaged POJOs except for your classes
extending
WebPage which are managed. I've juste had a quick look at JSF
2.0
  and
never worked with it - but I worked with Wicket - so I did not
  expected
Wicket JEE6 integration to be a drop in replacement for JSF. I do
  think
Wicket is an alternative framework for JEE6, not a replacement of
the
reference framework.
   
On one hand JSF2 assumes that you are running a JEE6 AS, so it is
  tightly
integrated with CDI, and you got all the cool stuff like
injection,
   scopes,
bean validation, etc. On the other hand, Wicket doesn't assume
  anything
except a web container implementing the servlet spec, so it can't
have
   all
the cool stuff of CDI because it's not built around CDI.
   
I think the next step to make Wicket JEE6 integration going
further is
  to
provide some Maven quickstart archetypes, the Weld team is looking
for
contributors :
   http://in.relation.to/Bloggers/WeldArchetypesInTheSpotlight
   
Now that I have something working, and when I will have some spare
  time,
   my
next step is to create an archetype for Glassfish. And if some
people
  on
this list have some time, their help is of course welcome :)
   
  
  
   -
   To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
   For additional commands, e-mail: users-h...@wicket.apache.org
  
  
  
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket and JEE6

2010-03-30 Thread Olivier Bourgeois
I do also think that it's because Wicket is not a managed framework :
everything is simple unmanaged POJOs except for your classes extending
WebPage which are managed. I've juste had a quick look at JSF 2.0 and
never worked with it - but I worked with Wicket - so I did not expected
Wicket JEE6 integration to be a drop in replacement for JSF. I do think
Wicket is an alternative framework for JEE6, not a replacement of the
reference framework.

On one hand JSF2 assumes that you are running a JEE6 AS, so it is tightly
integrated with CDI, and you got all the cool stuff like injection, scopes,
bean validation, etc. On the other hand, Wicket doesn't assume anything
except a web container implementing the servlet spec, so it can't have all
the cool stuff of CDI because it's not built around CDI.

I think the next step to make Wicket JEE6 integration going further is to
provide some Maven quickstart archetypes, the Weld team is looking for
contributors : http://in.relation.to/Bloggers/WeldArchetypesInTheSpotlight

Now that I have something working, and when I will have some spare time, my
next step is to create an archetype for Glassfish. And if some people on
this list have some time, their help is of course welcome :)


Re: Wicket and JEE6

2010-03-30 Thread Cemal Bayramoglu
Olivier,

I got Jame's stuff [1] up and running (thanks James) with just a few
small changes to the POMs - maybe he has stuff already in his local
Maven repo that is no longer on the main public repos) working with
little effort.

If you'd like to make (and maintain ;-) an archetype out of those
(based on Apache implementations), or a Galssfish based one,  we would
be happy to include those on our LegUp page [2][3].

Regards - Cemal
jWeekend
OO  Java Technologies, Wicket
Consulting, Development, Training
http://jWeekend.com

[1] http://svn.carmanconsulting.com/public/wicket-cdi/trunk
[2] http://jweekend.com/dev/LegUp
[3] http://code.google.com/p/legup/


On 30 March 2010 10:24, Olivier Bourgeois
olivier.bourgeois@gmail.com wrote:
 I do also think that it's because Wicket is not a managed framework :
 everything is simple unmanaged POJOs except for your classes extending
 WebPage which are managed. I've juste had a quick look at JSF 2.0 and
 never worked with it - but I worked with Wicket - so I did not expected
 Wicket JEE6 integration to be a drop in replacement for JSF. I do think
 Wicket is an alternative framework for JEE6, not a replacement of the
 reference framework.

 On one hand JSF2 assumes that you are running a JEE6 AS, so it is tightly
 integrated with CDI, and you got all the cool stuff like injection, scopes,
 bean validation, etc. On the other hand, Wicket doesn't assume anything
 except a web container implementing the servlet spec, so it can't have all
 the cool stuff of CDI because it's not built around CDI.

 I think the next step to make Wicket JEE6 integration going further is to
 provide some Maven quickstart archetypes, the Weld team is looking for
 contributors : http://in.relation.to/Bloggers/WeldArchetypesInTheSpotlight

 Now that I have something working, and when I will have some spare time, my
 next step is to create an archetype for Glassfish. And if some people on
 this list have some time, their help is of course welcome :)


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket and JEE6

2010-03-30 Thread James Carman
Cemal,

Please feel free to send me a patch if anything looks crazy.  I have had a
heck of a time getting all this stuff working.  It's a delicate balance
(like herding cats)! :)  The OWB folks have checked in my patch to fix one
of the issues, but we're still hammering out another.

Thanks,

James

On Tue, Mar 30, 2010 at 7:05 AM, Cemal Bayramoglu 
jweekend_for...@cabouge.com wrote:

 Olivier,

 I got Jame's stuff [1] up and running (thanks James) with just a few
 small changes to the POMs - maybe he has stuff already in his local
 Maven repo that is no longer on the main public repos) working with
 little effort.

 If you'd like to make (and maintain ;-) an archetype out of those
 (based on Apache implementations), or a Galssfish based one,  we would
 be happy to include those on our LegUp page [2][3].

 Regards - Cemal
 jWeekend
 OO  Java Technologies, Wicket
 Consulting, Development, Training
 http://jWeekend.com

 [1] http://svn.carmanconsulting.com/public/wicket-cdi/trunk
 [2] http://jweekend.com/dev/LegUp
 [3] http://code.google.com/p/legup/


 On 30 March 2010 10:24, Olivier Bourgeois
 olivier.bourgeois@gmail.com wrote:
  I do also think that it's because Wicket is not a managed framework :
  everything is simple unmanaged POJOs except for your classes extending
  WebPage which are managed. I've juste had a quick look at JSF 2.0 and
  never worked with it - but I worked with Wicket - so I did not expected
  Wicket JEE6 integration to be a drop in replacement for JSF. I do think
  Wicket is an alternative framework for JEE6, not a replacement of the
  reference framework.
 
  On one hand JSF2 assumes that you are running a JEE6 AS, so it is tightly
  integrated with CDI, and you got all the cool stuff like injection,
 scopes,
  bean validation, etc. On the other hand, Wicket doesn't assume anything
  except a web container implementing the servlet spec, so it can't have
 all
  the cool stuff of CDI because it's not built around CDI.
 
  I think the next step to make Wicket JEE6 integration going further is to
  provide some Maven quickstart archetypes, the Weld team is looking for
  contributors :
 http://in.relation.to/Bloggers/WeldArchetypesInTheSpotlight
 
  Now that I have something working, and when I will have some spare time,
 my
  next step is to create an archetype for Glassfish. And if some people on
  this list have some time, their help is of course welcome :)
 

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: Wicket and JEE6

2010-03-30 Thread Cemal Bayramoglu
James,

See the patch below; please double-check but it should be still valid
if you haven't updated your POMs since Sunday AM your time.

Regards - Cemal
jWeekend
OO  Java Technologies, Wicket
Consulting, Development, Training
http://jWeekend.com

== PATCH STARTS BELOW =
Index: pom.xml
===
--- pom.xml (revision 78)
+++ pom.xml (working copy)
@@ -36,4 +36,22 @@
 /plugin
 /plugins
 /build
+
+ repositories
+repository
+idJBoss Repo/id
+urlhttp://repository.jboss.com/maven2/url
+/repository
+
+ repository
+   idgeronimo-snapshots/id
+   nameApache Nexus Snapshots/name
+
urlhttps://repository.apache.org/content/groups/snapshots-group/url
+   snapshots
+ enabledtrue/enabled
+   /snapshots
+ /repository
+
+/repositories
+
 /project
\ No newline at end of file
Index: owb/pom.xml
===
--- owb/pom.xml (revision 78)
+++ owb/pom.xml (working copy)
@@ -16,11 +16,12 @@
 artifactIdwicket-cdi/artifactId
 version${project.version}/version
 /dependency
-dependency
-groupIdorg.apache.openwebbeans/groupId
-artifactIdopenwebbeans-impl/artifactId
-version1.0.0-SNAPSHOT/version
-/dependency
+dependency
+groupIdorg.apache.openwebbeans/groupId
+artifactIdopenwebbeans-impl/artifactId
+version1.0.0-M4/version
+/dependency
+
 dependency
 groupIdorg.apache.geronimo.specs/groupId
 artifactIdgeronimo-jcdi_1.0_spec/artifactId
Index: owb-example/pom.xml
===
--- owb-example/pom.xml (revision 78)
+++ owb-example/pom.xml (working copy)
@@ -62,15 +62,11 @@
 artifactIdwicket-cdi-owb/artifactId
 version${project.version}/version
 /dependency
-dependency
-groupIdorg.apache.openwebbeans/groupId
-artifactIdopenwebbeans-web/artifactId
-version1.0.0-SNAPSHOT/version
-/dependency
+
 dependency
 groupIdorg.apache.openwebbeans/groupId
 artifactIdopenwebbeans-spi/artifactId
-version1.0.0-SNAPSHOT/version
+version1.0.0-M4/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.specs/groupId
== END OF PATCH ABOVE 

On 30 March 2010 12:09, James Carman jcar...@carmanconsulting.com wrote:
 Cemal,

 Please feel free to send me a patch if anything looks crazy.  I have had a
 heck of a time getting all this stuff working.  It's a delicate balance
 (like herding cats)! :)  The OWB folks have checked in my patch to fix one
 of the issues, but we're still hammering out another.

 Thanks,

 James

 On Tue, Mar 30, 2010 at 7:05 AM, Cemal Bayramoglu 
 jweekend_for...@cabouge.com wrote:

 Olivier,

 I got Jame's stuff [1] up and running (thanks James) with just a few
 small changes to the POMs - maybe he has stuff already in his local
 Maven repo that is no longer on the main public repos) working with
 little effort.

 If you'd like to make (and maintain ;-) an archetype out of those
 (based on Apache implementations), or a Galssfish based one,  we would
 be happy to include those on our LegUp page [2][3].

 Regards - Cemal
 jWeekend
 OO  Java Technologies, Wicket
 Consulting, Development, Training
 http://jWeekend.com

 [1] http://svn.carmanconsulting.com/public/wicket-cdi/trunk
 [2] http://jweekend.com/dev/LegUp
 [3] http://code.google.com/p/legup/


 On 30 March 2010 10:24, Olivier Bourgeois
 olivier.bourgeois@gmail.com wrote:
  I do also think that it's because Wicket is not a managed framework :
  everything is simple unmanaged POJOs except for your classes extending
  WebPage which are managed. I've juste had a quick look at JSF 2.0 and
  never worked with it - but I worked with Wicket - so I did not expected
  Wicket JEE6 integration to be a drop in replacement for JSF. I do think
  Wicket is an alternative framework for JEE6, not a replacement of the
  reference framework.
 
  On one hand JSF2 assumes that you are running a JEE6 AS, so it is tightly
  integrated with CDI, and you got all the cool stuff like injection,
 scopes,
  bean validation, etc. On the other hand, Wicket doesn't assume anything
  except a web container implementing the servlet spec, so it can't have
 all
  the cool stuff of CDI because it's not built around CDI.
 
  I think the next step to make Wicket JEE6 integration going further is to
  provide some Maven quickstart archetypes, the Weld team is looking for
  contributors :
 http://in.relation.to/Bloggers/WeldArchetypesInTheSpotlight
 
  Now that I have something working, and when I will have some

Re: Wicket and JEE6

2010-03-30 Thread James Carman
I was using M4 of OWB, but I had to patch it.  Are you sure it works for
you?  I was getting a NPE.

On Tue, Mar 30, 2010 at 7:22 AM, Cemal Bayramoglu 
jweekend_for...@cabouge.com wrote:

 James,

 See the patch below; please double-check but it should be still valid
 if you haven't updated your POMs since Sunday AM your time.

 Regards - Cemal
 jWeekend
 OO  Java Technologies, Wicket
 Consulting, Development, Training
 http://jWeekend.com

 == PATCH STARTS BELOW =
 Index: pom.xml
 ===
 --- pom.xml (revision 78)
 +++ pom.xml (working copy)
 @@ -36,4 +36,22 @@
 /plugin
 /plugins
 /build
 +
 + repositories
 +repository
 +idJBoss Repo/id
 +urlhttp://repository.jboss.com/maven2/url
 +/repository
 +
 + repository
 +   idgeronimo-snapshots/id
 +   nameApache Nexus Snapshots/name
 +
 urlhttps://repository.apache.org/content/groups/snapshots-group/url
 +   snapshots
 + enabledtrue/enabled
 +   /snapshots
 + /repository
 +
 +/repositories
 +
  /project
 \ No newline at end of file
 Index: owb/pom.xml
 ===
 --- owb/pom.xml (revision 78)
 +++ owb/pom.xml (working copy)
 @@ -16,11 +16,12 @@
 artifactIdwicket-cdi/artifactId
 version${project.version}/version
 /dependency
 -dependency
 -groupIdorg.apache.openwebbeans/groupId
 -artifactIdopenwebbeans-impl/artifactId
 -version1.0.0-SNAPSHOT/version
 -/dependency
 +dependency
 +groupIdorg.apache.openwebbeans/groupId
 +artifactIdopenwebbeans-impl/artifactId
 +version1.0.0-M4/version
 +/dependency
 +
 dependency
 groupIdorg.apache.geronimo.specs/groupId
 artifactIdgeronimo-jcdi_1.0_spec/artifactId
 Index: owb-example/pom.xml
 ===
 --- owb-example/pom.xml (revision 78)
 +++ owb-example/pom.xml (working copy)
 @@ -62,15 +62,11 @@
 artifactIdwicket-cdi-owb/artifactId
 version${project.version}/version
 /dependency
 -dependency
 -groupIdorg.apache.openwebbeans/groupId
 -artifactIdopenwebbeans-web/artifactId
 -version1.0.0-SNAPSHOT/version
 -/dependency
 +
 dependency
 groupIdorg.apache.openwebbeans/groupId
 artifactIdopenwebbeans-spi/artifactId
 -version1.0.0-SNAPSHOT/version
 +version1.0.0-M4/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.specs/groupId
 == END OF PATCH ABOVE 

 On 30 March 2010 12:09, James Carman jcar...@carmanconsulting.com wrote:
  Cemal,
 
  Please feel free to send me a patch if anything looks crazy.  I have had
 a
  heck of a time getting all this stuff working.  It's a delicate balance
  (like herding cats)! :)  The OWB folks have checked in my patch to fix
 one
  of the issues, but we're still hammering out another.
 
  Thanks,
 
  James
 
  On Tue, Mar 30, 2010 at 7:05 AM, Cemal Bayramoglu 
  jweekend_for...@cabouge.com wrote:
 
  Olivier,
 
  I got Jame's stuff [1] up and running (thanks James) with just a few
  small changes to the POMs - maybe he has stuff already in his local
  Maven repo that is no longer on the main public repos) working with
  little effort.
 
  If you'd like to make (and maintain ;-) an archetype out of those
  (based on Apache implementations), or a Galssfish based one,  we would
  be happy to include those on our LegUp page [2][3].
 
  Regards - Cemal
  jWeekend
  OO  Java Technologies, Wicket
  Consulting, Development, Training
  http://jWeekend.com
 
  [1] http://svn.carmanconsulting.com/public/wicket-cdi/trunk
  [2] http://jweekend.com/dev/LegUp
  [3] http://code.google.com/p/legup/
 
 
  On 30 March 2010 10:24, Olivier Bourgeois
  olivier.bourgeois@gmail.com wrote:
   I do also think that it's because Wicket is not a managed framework :
   everything is simple unmanaged POJOs except for your classes extending
   WebPage which are managed. I've juste had a quick look at JSF 2.0
 and
   never worked with it - but I worked with Wicket - so I did not
 expected
   Wicket JEE6 integration to be a drop in replacement for JSF. I do
 think
   Wicket is an alternative framework for JEE6, not a replacement of the
   reference framework.
  
   On one hand JSF2 assumes that you are running a JEE6 AS, so it is
 tightly
   integrated with CDI, and you got all the cool stuff like injection,
  scopes,
   bean validation, etc. On the other hand, Wicket doesn't assume
 anything
   except a web container implementing the servlet spec, so it can't have
  all
   the cool stuff of CDI because it's

Re: Wicket and JEE6

2010-03-30 Thread Cemal Bayramoglu
James,

I'm pretty sure mvn test ran successfully on all your projects once
I patched the POMs.
I ran some (maybe not all) of the demo apps too.
Send me your patches if you like too (they must not have been deployed
yet on Sunday) and I may be able to take another look this evening or
tomorrow PM.

Regards - Cemal
jWeekend
OO  Java Technologies, Wicket
Consulting, Development, Training
http://jWeekend.com

On 30 March 2010 12:30, James Carman jcar...@carmanconsulting.com wrote:
 I was using M4 of OWB, but I had to patch it.  Are you sure it works for
 you?  I was getting a NPE.

 On Tue, Mar 30, 2010 at 7:22 AM, Cemal Bayramoglu 
 jweekend_for...@cabouge.com wrote:

 James,

 See the patch below; please double-check but it should be still valid
 if you haven't updated your POMs since Sunday AM your time.

 Regards - Cemal
 jWeekend
 OO  Java Technologies, Wicket
 Consulting, Development, Training
 http://jWeekend.com

 == PATCH STARTS BELOW =
 Index: pom.xml
 ===
 --- pom.xml     (revision 78)
 +++ pom.xml     (working copy)
 @@ -36,4 +36,22 @@
             /plugin
         /plugins
     /build
 +
 +     repositories
 +        repository
 +            idJBoss Repo/id
 +            urlhttp://repository.jboss.com/maven2/url
 +        /repository
 +
 +         repository
 +               idgeronimo-snapshots/id
 +               nameApache Nexus Snapshots/name
 +
 urlhttps://repository.apache.org/content/groups/snapshots-group/url
 +               snapshots
 +                 enabledtrue/enabled
 +               /snapshots
 +         /repository
 +
 +    /repositories
 +
  /project
 \ No newline at end of file
 Index: owb/pom.xml
 ===
 --- owb/pom.xml (revision 78)
 +++ owb/pom.xml (working copy)
 @@ -16,11 +16,12 @@
             artifactIdwicket-cdi/artifactId
             version${project.version}/version
         /dependency
 -        dependency
 -            groupIdorg.apache.openwebbeans/groupId
 -            artifactIdopenwebbeans-impl/artifactId
 -            version1.0.0-SNAPSHOT/version
 -        /dependency
 +dependency
 +    groupIdorg.apache.openwebbeans/groupId
 +    artifactIdopenwebbeans-impl/artifactId
 +    version1.0.0-M4/version
 +/dependency
 +
         dependency
             groupIdorg.apache.geronimo.specs/groupId
             artifactIdgeronimo-jcdi_1.0_spec/artifactId
 Index: owb-example/pom.xml
 ===
 --- owb-example/pom.xml (revision 78)
 +++ owb-example/pom.xml (working copy)
 @@ -62,15 +62,11 @@
             artifactIdwicket-cdi-owb/artifactId
             version${project.version}/version
         /dependency
 -        dependency
 -            groupIdorg.apache.openwebbeans/groupId
 -            artifactIdopenwebbeans-web/artifactId
 -            version1.0.0-SNAPSHOT/version
 -        /dependency
 +
         dependency
             groupIdorg.apache.openwebbeans/groupId
             artifactIdopenwebbeans-spi/artifactId
 -            version1.0.0-SNAPSHOT/version
 +            version1.0.0-M4/version
         /dependency
         dependency
             groupIdorg.apache.geronimo.specs/groupId
 == END OF PATCH ABOVE 

 On 30 March 2010 12:09, James Carman jcar...@carmanconsulting.com wrote:
  Cemal,
 
  Please feel free to send me a patch if anything looks crazy.  I have had
 a
  heck of a time getting all this stuff working.  It's a delicate balance
  (like herding cats)! :)  The OWB folks have checked in my patch to fix
 one
  of the issues, but we're still hammering out another.
 
  Thanks,
 
  James
 
  On Tue, Mar 30, 2010 at 7:05 AM, Cemal Bayramoglu 
  jweekend_for...@cabouge.com wrote:
 
  Olivier,
 
  I got Jame's stuff [1] up and running (thanks James) with just a few
  small changes to the POMs - maybe he has stuff already in his local
  Maven repo that is no longer on the main public repos) working with
  little effort.
 
  If you'd like to make (and maintain ;-) an archetype out of those
  (based on Apache implementations), or a Galssfish based one,  we would
  be happy to include those on our LegUp page [2][3].
 
  Regards - Cemal
  jWeekend
  OO  Java Technologies, Wicket
  Consulting, Development, Training
  http://jWeekend.com
 
  [1] http://svn.carmanconsulting.com/public/wicket-cdi/trunk
  [2] http://jweekend.com/dev/LegUp
  [3] http://code.google.com/p/legup/
 
 
  On 30 March 2010 10:24, Olivier Bourgeois
  olivier.bourgeois@gmail.com wrote:
   I do also think that it's because Wicket is not a managed framework :
   everything is simple unmanaged POJOs except for your classes extending
   WebPage which are managed. I've juste had a quick look at JSF 2.0
 and
   never worked with it - but I worked with Wicket - so I did not
 expected
   Wicket JEE6 integration to be a drop

Re: Wicket and JEE6

2010-03-30 Thread James Carman
   be happy to include those on our LegUp page [2][3].
  
   Regards - Cemal
   jWeekend
   OO  Java Technologies, Wicket
   Consulting, Development, Training
   http://jWeekend.com
  
   [1] http://svn.carmanconsulting.com/public/wicket-cdi/trunk
   [2] http://jweekend.com/dev/LegUp
   [3] http://code.google.com/p/legup/
  
  
   On 30 March 2010 10:24, Olivier Bourgeois
   olivier.bourgeois@gmail.com wrote:
I do also think that it's because Wicket is not a managed framework
 :
everything is simple unmanaged POJOs except for your classes
 extending
WebPage which are managed. I've juste had a quick look at JSF 2.0
  and
never worked with it - but I worked with Wicket - so I did not
  expected
Wicket JEE6 integration to be a drop in replacement for JSF. I do
  think
Wicket is an alternative framework for JEE6, not a replacement of
 the
reference framework.
   
On one hand JSF2 assumes that you are running a JEE6 AS, so it is
  tightly
integrated with CDI, and you got all the cool stuff like injection,
   scopes,
bean validation, etc. On the other hand, Wicket doesn't assume
  anything
except a web container implementing the servlet spec, so it can't
 have
   all
the cool stuff of CDI because it's not built around CDI.
   
I think the next step to make Wicket JEE6 integration going further
 is
  to
provide some Maven quickstart archetypes, the Weld team is looking
 for
contributors :
   http://in.relation.to/Bloggers/WeldArchetypesInTheSpotlight
   
Now that I have something working, and when I will have some spare
  time,
   my
next step is to create an archetype for Glassfish. And if some
 people
  on
this list have some time, their help is of course welcome :)
   
  
   -
   To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
   For additional commands, e-mail: users-h...@wicket.apache.org
  
  
  
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: Wicket and JEE6

2010-03-30 Thread Olivier Bourgeois
2010/3/30 Cemal Bayramoglu jweekend_for...@cabouge.com

 Olivier,

 I got Jame's stuff [1] up and running (thanks James) with just a few
 small changes to the POMs - maybe he has stuff already in his local
 Maven repo that is no longer on the main public repos) working with
 little effort.

 If you'd like to make (and maintain ;-) an archetype out of those
 (based on Apache implementations), or a Galssfish based one,  we would
 be happy to include those on our LegUp page [2][3].

 Regards - Cemal
 jWeekend
 OO  Java Technologies, Wicket
 Consulting, Development, Training
 http://jWeekend.com

 [1] http://svn.carmanconsulting.com/public/wicket-cdi/trunk
 [2] http://jweekend.com/dev/LegUp
 [3] http://code.google.com/p/legup/


Cemal,

thanks for the offer I'll keep this in mind.

James,

  you need an empty beans.xml file to let Weld know what to scan, this is
explained much further in this blog entry :

http://relation.to/Bloggers/WhyIsBeansxmlRequiredInCDI

And if you plan to build a Weld extension, you must know that you have to
create a file named :

META-INF/services/javax.enterprise.inject.spi.Extension

containing the full qualified name of your class implementing Extension.


Re: Wicket and JEE6

2010-03-30 Thread James Carman
On Tue, Mar 30, 2010 at 10:21 AM, Olivier Bourgeois
olivier.bourgeois@gmail.com wrote:
 James,

  you need an empty beans.xml file to let Weld know what to scan, this is
 explained much further in this blog entry :

 http://relation.to/Bloggers/WhyIsBeansxmlRequiredInCDI


Yeah, I guess I figured that out the hard way! :)  I believe OWB works
the same way.  I found a JIRA issue or something that clued me in.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket and JEE6

2010-03-30 Thread Iskandar Salim



Olivier Bourgeois-2 wrote:
 
 ...
 everything is simple unmanaged POJOs except for your classes extending
 WebPage which are managed
 

Not to be picky but a minor correction :)
everything is simple unmanaged POJOs except for your classes extending
[Component] which are managed


-- 
View this message in context: 
http://old.nabble.com/Wicket-and-JEE6-tp28045129p28091022.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



RE: Wicket and JEE6

2010-03-29 Thread Iskandar Salim


Ericksen, Mark W (IS) wrote:
 
 java.lang.NoSuchMethodError:
 org.jboss.weld.Container.services()Lorg/jboss/weld/bootstrap/api/Service
 Registry;
 

You need to update your weld-integration.jar (and maybe weld-osgi.jar) files
in ${glassfish_install_dir}/glassfish/modules

Get weld-integration.jar here 
http://download.java.net/maven/glassfish/org/glassfish/web/weld-integration/
here/  The 3.0.1-b10 version works for me.

and weld-osgi.jar 
http://repo2.maven.org/maven2/org/jboss/weld/weld-osgi-bundle/ here 

-- 
View this message in context: 
http://old.nabble.com/Wicket-and-JEE6-tp28045129p28065312.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket and JEE6

2010-03-29 Thread Olivier Bourgeois
Hi,

Wicket has very good support in Weld, but to make it work I had to update
the weld-integration.jar, otherwise the sample Numberguess application is
looking for an unexisting method in the 1.0.0 Weld API : this is your
problem.

If you don't want to do it by hand like suggested by Iskandar, you can
download one of the Glassfish nightly builds, this is what I have done. The
latest builds are integrating Weld 1.0.1-final and the problem vanishes.

If you want, I can provide you the maven profile to make the sample work
nicely when you hit the run button in Netbeans, because there is another
problem with the samples : the maven profile is not including the slf4j
libraries, so there is an error in Glassfish when you run the sample. I
assume this may be your next problem :)

Also, you may run into trouble with the JPA2 code generation if you are
using maven. But if you are using Eclipse annotation preprocessor to
generate the metadata, you won't have the problem.

--
Olivier


RE: Wicket and JEE6

2010-03-29 Thread Ericksen, Mark W (IS)
Thanks Olivier, Iskandar, and James!

After getting Weld integration to work with the weld-wicket jar I
realized that the integration is limited to classes that subclass from
WebPage (or Page I suppose) to work within a request cycle.  I cannot
inject a DAO into a session or a singleton into an application class for
example.  In a JSF2 project there is no limitations.  Plus the ability
to annotate scope would be nice.

This makes me wonder what the future holds for Wicket and JEE6.  Is
there work being done to fully integrate Wicket with JEE6's newly
defined set of supported JSRs?

It would be nice to see a comparison chart of JEE6 features and Wicket's
current and expected future support for such features.  I've been
searching for something like this but haven't found anything.

I'd love to see Wicket fully support JEE6 and become a drop in
replacement for JSF2.  This doesn't seem to be the case just yet.  If
I'm wrong be sure to let me know! 

-Mark



-Original Message-
From: Olivier Bourgeois [mailto:olivier.bourgeois@gmail.com] 
Sent: Monday, March 29, 2010 2:45 AM
To: users@wicket.apache.org
Subject: Re: Wicket and JEE6

Hi,

Wicket has very good support in Weld, but to make it work I had to
update
the weld-integration.jar, otherwise the sample Numberguess application
is
looking for an unexisting method in the 1.0.0 Weld API : this is your
problem.

If you don't want to do it by hand like suggested by Iskandar, you can
download one of the Glassfish nightly builds, this is what I have done.
The
latest builds are integrating Weld 1.0.1-final and the problem vanishes.

If you want, I can provide you the maven profile to make the sample work
nicely when you hit the run button in Netbeans, because there is
another
problem with the samples : the maven profile is not including the slf4j
libraries, so there is an error in Glassfish when you run the sample. I
assume this may be your next problem :)

Also, you may run into trouble with the JPA2 code generation if you are
using maven. But if you are using Eclipse annotation preprocessor to
generate the metadata, you won't have the problem.

--
Olivier

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket and JEE6

2010-03-29 Thread James Carman
The problem you're going to face is that Wicket is an unmanaged
framework.  Meaning that something else doesn't create stuff for you.  You
create your Links, Labels, TextFields, etc.  So, the container can't really
do the injection.  Now, what we could come up with would be an aspect that
does the dirty work for you, but that would mean that you have to introduce
AspectJ into your build (not a big deal).  It would be interesting to see
how this works.

By the way, with my stuff, you can just do
AbstractCdiPlugin.get().inject(whateverObject) and it will do the injection
for you.  So, you can put that in your session class' constructor, for
instance.  For the application, you can use the plugin's inject() method
inside your init() method (you have to instantiate and install it there
anyway).

On Mon, Mar 29, 2010 at 1:23 PM, Ericksen, Mark W (IS) 
mark.erick...@ngc.com wrote:

 Thanks Olivier, Iskandar, and James!

 After getting Weld integration to work with the weld-wicket jar I
 realized that the integration is limited to classes that subclass from
 WebPage (or Page I suppose) to work within a request cycle.  I cannot
 inject a DAO into a session or a singleton into an application class for
 example.  In a JSF2 project there is no limitations.  Plus the ability
 to annotate scope would be nice.

 This makes me wonder what the future holds for Wicket and JEE6.  Is
 there work being done to fully integrate Wicket with JEE6's newly
 defined set of supported JSRs?

 It would be nice to see a comparison chart of JEE6 features and Wicket's
 current and expected future support for such features.  I've been
 searching for something like this but haven't found anything.

 I'd love to see Wicket fully support JEE6 and become a drop in
 replacement for JSF2.  This doesn't seem to be the case just yet.  If
 I'm wrong be sure to let me know!

 -Mark



 -Original Message-
 From: Olivier Bourgeois [mailto:olivier.bourgeois@gmail.com]
 Sent: Monday, March 29, 2010 2:45 AM
 To: users@wicket.apache.org
 Subject: Re: Wicket and JEE6

 Hi,

 Wicket has very good support in Weld, but to make it work I had to
 update
 the weld-integration.jar, otherwise the sample Numberguess application
 is
 looking for an unexisting method in the 1.0.0 Weld API : this is your
 problem.

 If you don't want to do it by hand like suggested by Iskandar, you can
 download one of the Glassfish nightly builds, this is what I have done.
 The
 latest builds are integrating Weld 1.0.1-final and the problem vanishes.

 If you want, I can provide you the maven profile to make the sample work
 nicely when you hit the run button in Netbeans, because there is
 another
 problem with the samples : the maven profile is not including the slf4j
 libraries, so there is an error in Glassfish when you run the sample. I
 assume this may be your next problem :)

 Also, you may run into trouble with the JPA2 code generation if you are
 using maven. But if you are using Eclipse annotation preprocessor to
 generate the metadata, you won't have the problem.

 --
 Olivier

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: Wicket and JEE6

2010-03-27 Thread James Carman
Ok, I've got the OWB examples working now with my local patched version of
OWB (patches submitted to JIRA).  Also, note I've renamed the library to
wicket-cdi:

http://svn.carmanconsulting.com/public/wicket-cdi/trunk


On Sat, Mar 27, 2010 at 1:39 AM, James Carman
jcar...@carmanconsulting.comwrote:

 I've got a working example with Weld.  Check
 http://svn.carmanconsulting.com/public/wicket-candi/trunk

 There's a weld-example subdirectory in there.  Currently, I don't have the
 conversation stuff working, but the injections appear to be working.
 Unfortunately, the implementation doesn't work with OWB. :(  I'll see what's
 causing it and see if we can get them both working.  Good luck.

 On Fri, Mar 26, 2010 at 6:35 PM, Ericksen, Mark W (IS) 
 mark.erick...@ngc.com wrote:

 Thanks Josh.

 With your idea in mind I dug deeper into what Weld's support for Wicket
 is/was.
 In the Weld download is a jar called weld-wicket.jar that has a
 WeldApplication class for doing what you suggest.  However following the
 instruction for using their integration code only got me an error when
 including their jar in my project.
 java.lang.NoSuchMethodError:
 org.jboss.weld.Container.services()Lorg/jboss/weld/bootstrap/api/Service
 Registry;

 So I included the weld-wicket code in my simple project to see what was
 going on.  Their integration solution provides a new RequestCycle class
 called WeldRequestCycle.  In this class they attempt to preserve a long
 running conversation through weld/wicket trickery.  There's a line of
 code in a few places that causes a runtime exception that stops the
 request cycle.

 ConversationContext conversationContext =
 Container.instance().services().get(ContextLifecycle.class).getConversat
 ionContext();

 These are Weld classes, but stepping through the debugger shows it goes
 go back through the Wicket filter.  Therefore I don't know who is at
 fault here.  Maybe something in Wicket changed that is causing Weld to
 croak or Weld in Glassfish is the culprit.  Either way I really don't
 care about long running conversation support at this point so I removed
 the class and any dependency on it in my modified version of the
 weld-wicket code base.

 With that exception out of the way and changing my application to
 subclass from WeldApplication, I have simple injection working with
 Weld.  Yippee!  I'll cross my fingers there are no other side effects.

 Problem is now what?  I guess I can post this with the Seam/Weld team
 and hope someone updates the Weld-Wicket integration.  Or I can hope
 someone from the Wicket team will take a look and see if it's something
 in the latest version of Wicket that caused this to break and could do a
 patch.

 Anyone? :)

 -Mark

 -Original Message-
 From: Josh Chappelle [mailto:jchappe...@4redi.com]
 Sent: Friday, March 26, 2010 2:59 PM
 To: users@wicket.apache.org
 Subject: RE: Wicket and JEE6

 Mark,

 Try taking a look at the addComponentInstantiationListener method on the
 Application class. It takes one parameter of type
 IComponentInstantiationListener and that interface has one method which
 is
 onInstantiation(Component component). Every time a component gets
 instantiated it will be handed to this listener so maybe you can write
 your
 own dependency injection code there. I would think that is what the
 WeldApplication is doing under the covers but since it isn't working for
 you
 then you may have more luck just writing it yourself. The other trick is
 to
 making this work is obtaining a reference to your weld context. I use
 Spring
 so I'm not familiar with what it takes with Weld.

 I hope this helps.

 Thanks,

 Josh

 -Original Message-
 From: Ericksen, Mark W (IS) [mailto:mark.erick...@ngc.com]
 Sent: Friday, March 26, 2010 11:52 AM
 To: users@wicket.apache.org
 Subject: Wicket and JEE6

 Hi,



 I'm building a new java project using all JEE6 technologies.  That means
 I'm using JPA, CDI, and JSF2 for example. Each layer came together great
 with fully annotated classes until I got to the JSF2 layer which drove
 me crazy because JSF wants to mess with HTML element ids and names.   In
 looking for alternative view layers I came across Wicket.  The
 technology seems great in terms of its philosophy to keep presentation
 code separate, except I'm not finding much information about its support
 for JEE6 technologies.



 In particular searches for support for CDI (aka WebBeans, aka Weld) only
 got me to an old example in the Seam project.  I cannot find any current
 references to using Weld within a Wicket project where I can use
 annotations such as @Inject, @Named, @ApplicationScoped, etc.



 So my very first question for this list of experts is this:  Is there
 currently any support for Weld in Wicket?  Downloading the Weld project
 from JBoss, I included the weld-wicket.jar into my project and my
 application is subclassed from WeldApplication.  No such luck.  Any
 class injected using @Inject is still null.



 I am

Wicket and JEE6

2010-03-26 Thread Ericksen, Mark W (IS)
Hi,

 

I'm building a new java project using all JEE6 technologies.  That means
I'm using JPA, CDI, and JSF2 for example. Each layer came together great
with fully annotated classes until I got to the JSF2 layer which drove
me crazy because JSF wants to mess with HTML element ids and names.   In
looking for alternative view layers I came across Wicket.  The
technology seems great in terms of its philosophy to keep presentation
code separate, except I'm not finding much information about its support
for JEE6 technologies.

 

In particular searches for support for CDI (aka WebBeans, aka Weld) only
got me to an old example in the Seam project.  I cannot find any current
references to using Weld within a Wicket project where I can use
annotations such as @Inject, @Named, @ApplicationScoped, etc.  

 

So my very first question for this list of experts is this:  Is there
currently any support for Weld in Wicket?  Downloading the Weld project
from JBoss, I included the weld-wicket.jar into my project and my
application is subclassed from WeldApplication.  No such luck.  Any
class injected using @Inject is still null.

 

I am using GlassFish v3 which has all the JEE6 goodies included.
Developing with Eclipse.

 

Any help is *greatly* appreciated!

 

-Mark

 

 



Re: Wicket and JEE6

2010-03-26 Thread James Carman
Weld has wicket support built-in I believe.

On Fri, Mar 26, 2010 at 12:52 PM, Ericksen, Mark W (IS) 
mark.erick...@ngc.com wrote:

 Hi,



 I'm building a new java project using all JEE6 technologies.  That means
 I'm using JPA, CDI, and JSF2 for example. Each layer came together great
 with fully annotated classes until I got to the JSF2 layer which drove
 me crazy because JSF wants to mess with HTML element ids and names.   In
 looking for alternative view layers I came across Wicket.  The
 technology seems great in terms of its philosophy to keep presentation
 code separate, except I'm not finding much information about its support
 for JEE6 technologies.



 In particular searches for support for CDI (aka WebBeans, aka Weld) only
 got me to an old example in the Seam project.  I cannot find any current
 references to using Weld within a Wicket project where I can use
 annotations such as @Inject, @Named, @ApplicationScoped, etc.



 So my very first question for this list of experts is this:  Is there
 currently any support for Weld in Wicket?  Downloading the Weld project
 from JBoss, I included the weld-wicket.jar into my project and my
 application is subclassed from WeldApplication.  No such luck.  Any
 class injected using @Inject is still null.



 I am using GlassFish v3 which has all the JEE6 goodies included.
 Developing with Eclipse.



 Any help is *greatly* appreciated!



 -Mark








RE: Wicket and JEE6

2010-03-26 Thread Ericksen, Mark W (IS)
Weld claims support, I don't know about built-in.

When I use @Inject in a Wicket WebPage subclass the objects are null.
Like I mentioned below, I added weld-wicket.jar and subclassed the
WeldApplication and the injected objects in the Wicket WebPage subclass
are still null.

This was from following this example:
http://docs.jboss.org/weld/reference/1.0.0/en-US/html/viewlayers.html

If you track down the example code it seems that the examples from JBoss
are using older versions of Wicket and Weld/Seam so I don't know if
something has broken in either project, wicket or weld.

Injection worked like a charm in a JSF2 controller class so I don't know
what going wrong or what supporting jar is missing.

Any additional help is greatly appreciated!

-Mark


-Original Message-
From: James Carman [mailto:jcar...@carmanconsulting.com] 
Sent: Friday, March 26, 2010 10:52 AM
To: users@wicket.apache.org
Subject: Re: Wicket and JEE6

Weld has wicket support built-in I believe.

On Fri, Mar 26, 2010 at 12:52 PM, Ericksen, Mark W (IS) 
mark.erick...@ngc.com wrote:

 Hi,



 I'm building a new java project using all JEE6 technologies.  That
means
 I'm using JPA, CDI, and JSF2 for example. Each layer came together
great
 with fully annotated classes until I got to the JSF2 layer which drove
 me crazy because JSF wants to mess with HTML element ids and names.
In
 looking for alternative view layers I came across Wicket.  The
 technology seems great in terms of its philosophy to keep presentation
 code separate, except I'm not finding much information about its
support
 for JEE6 technologies.



 In particular searches for support for CDI (aka WebBeans, aka Weld)
only
 got me to an old example in the Seam project.  I cannot find any
current
 references to using Weld within a Wicket project where I can use
 annotations such as @Inject, @Named, @ApplicationScoped, etc.



 So my very first question for this list of experts is this:  Is there
 currently any support for Weld in Wicket?  Downloading the Weld
project
 from JBoss, I included the weld-wicket.jar into my project and my
 application is subclassed from WeldApplication.  No such luck.  Any
 class injected using @Inject is still null.



 I am using GlassFish v3 which has all the JEE6 goodies included.
 Developing with Eclipse.



 Any help is *greatly* appreciated!



 -Mark







-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket and JEE6

2010-03-26 Thread James Carman
I started a JSR-299 integration project a while back, but at the time there
was no portable way (across vendors) to get to the stuff you needed to
inject into your components.  I believe that's been fixed in the latest API,
but I haven't had a chance to dig in and verify that and then use it.  My
guess is that there's really not that much to it (my code was pretty
small).

On Fri, Mar 26, 2010 at 1:35 PM, Ericksen, Mark W (IS) 
mark.erick...@ngc.com wrote:

 Weld claims support, I don't know about built-in.

 When I use @Inject in a Wicket WebPage subclass the objects are null.
 Like I mentioned below, I added weld-wicket.jar and subclassed the
 WeldApplication and the injected objects in the Wicket WebPage subclass
 are still null.

 This was from following this example:
 http://docs.jboss.org/weld/reference/1.0.0/en-US/html/viewlayers.html

 If you track down the example code it seems that the examples from JBoss
 are using older versions of Wicket and Weld/Seam so I don't know if
 something has broken in either project, wicket or weld.

 Injection worked like a charm in a JSF2 controller class so I don't know
 what going wrong or what supporting jar is missing.

 Any additional help is greatly appreciated!

 -Mark


 -Original Message-
 From: James Carman [mailto:jcar...@carmanconsulting.com]
 Sent: Friday, March 26, 2010 10:52 AM
 To: users@wicket.apache.org
 Subject: Re: Wicket and JEE6

 Weld has wicket support built-in I believe.

 On Fri, Mar 26, 2010 at 12:52 PM, Ericksen, Mark W (IS) 
 mark.erick...@ngc.com wrote:

  Hi,
 
 
 
  I'm building a new java project using all JEE6 technologies.  That
 means
  I'm using JPA, CDI, and JSF2 for example. Each layer came together
 great
  with fully annotated classes until I got to the JSF2 layer which drove
  me crazy because JSF wants to mess with HTML element ids and names.
 In
  looking for alternative view layers I came across Wicket.  The
  technology seems great in terms of its philosophy to keep presentation
  code separate, except I'm not finding much information about its
 support
  for JEE6 technologies.
 
 
 
  In particular searches for support for CDI (aka WebBeans, aka Weld)
 only
  got me to an old example in the Seam project.  I cannot find any
 current
  references to using Weld within a Wicket project where I can use
  annotations such as @Inject, @Named, @ApplicationScoped, etc.
 
 
 
  So my very first question for this list of experts is this:  Is there
  currently any support for Weld in Wicket?  Downloading the Weld
 project
  from JBoss, I included the weld-wicket.jar into my project and my
  application is subclassed from WeldApplication.  No such luck.  Any
  class injected using @Inject is still null.
 
 
 
  I am using GlassFish v3 which has all the JEE6 goodies included.
  Developing with Eclipse.
 
 
 
  Any help is *greatly* appreciated!
 
 
 
  -Mark
 
 
 
 
 
 

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




RE: Wicket and JEE6

2010-03-26 Thread Ericksen, Mark W (IS)
Warning: Long Response with sample code to illustrate issue.

I ran the following code in Glassfish v3 with the following jars:
portlet-api_2.0_spec-1.0.jar   (someone is relying on this??)
slf4j-api-1.4.2.jar
slf4j-jdk14-1.4.2.jar
wicket-1.4.7.jar

Be sure to add an empty beans.xml to the WEB-INF folder.

After starting up Glassfish, type the following in the browser
(WicketTest is the name of my project, yours may vary):

localhost:8080/WicketTest/ 
The output it: No Util Class

localhost:8080/WicketTest/jsf.faces
The output is: Hello World!


Code follows


web.xml:

?xml version=1.0 encoding=UTF-8?
web-app xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:web=http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd; id=WebApp_ID
version=2.5
  display-nameWicketTest/display-name

  servlet
servlet-nameFaces Servlet/servlet-name
servlet-classjavax.faces.webapp.FacesServlet/servlet-class
load-on-startup1/load-on-startup
  /servlet

  servlet-mapping
servlet-nameFaces Servlet/servlet-name
url-pattern/faces/*/url-pattern
url-pattern*.faces/url-pattern
  /servlet-mapping

  filter
filter-namewicket example/filter-name
 
filter-classorg.apache.wicket.protocol.http.WicketFilter/filter-class

init-param
  param-nameapplicationClassName/param-name
  param-valuecom.example.wicket.ExampleApplication/param-value
/init-param
  /filter

  filter-mapping
filter-namewicket example/filter-name
url-pattern/*/url-pattern
  /filter-mapping

/web-app


EntityUtil.java:

package com.example.wicket;

public class EntityUtil {

public String getEntity() {
return Hello World!;
}
}


ExampleApplication.java:


package com.example.wicket;

import org.apache.wicket.Page;
import org.apache.wicket.protocol.http.WebApplication;


public class ExampleApplication extends WebApplication {


@Override
public Class? extends Page getHomePage() {
return HomePage.class;
}

}


HomePage.java:


package com.example.wicket;

import javax.inject.Inject;

import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.model.Model;



public class HomePage extends WebPage {

@Inject private EntityUtil util;

public HomePage() {
super();
add(new Label(hello, new ModelString(this.getHello(;
}

private String getHello() { return (null != util) ? util.getEntity()
: No Util Class; }
}


HomePage.html:


!DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
http://www.w3.org/TR/html4/loose.dtd;
html xmlns:wicket=http://wicket.apache.org;
  head
meta http-equiv=Content-Type content=text/html;
charset=ISO-8859-1
titleInsert wicket title here/title
  /head
  body
span wicket:id=helloYo!/span
  /body
/html


jsf.xhtml (in context root):


!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;

html xmlns=http://www.w3.org/1999/xhtml;
  xmlns:h=http://java.sun.com/jsf/html;

  h:head
  titleInsert jsf title here/title
  /h:head
  h:body
span#{controller.hello}/span
  /h:body
/html


Controller.java:


package com.example.wicket;

import javax.enterprise.context.RequestScoped;
import javax.inject.Inject;
import javax.inject.Named;


@Named  @RequestScoped
public class Controller {

@Inject private EntityUtil util;

public String getHello() { return (null != util) ? util.getEntity()
: No Util Class; }
}






-Original Message-
From: James Carman [mailto:jcar...@carmanconsulting.com] 
Sent: Friday, March 26, 2010 11:36 AM
To: users@wicket.apache.org
Subject: Re: Wicket and JEE6

I started a JSR-299 integration project a while back, but at the time
there
was no portable way (across vendors) to get to the stuff you needed to
inject into your components.  I believe that's been fixed in the latest
API,
but I haven't had a chance to dig in and verify that and then use it.
My
guess is that there's really not that much to it (my code was pretty
small).

On Fri, Mar 26, 2010 at 1:35 PM, Ericksen, Mark W (IS) 
mark.erick...@ngc.com wrote:

 Weld claims support, I don't know about built-in.

 When I use @Inject in a Wicket WebPage subclass the objects are null.
 Like I mentioned below, I added weld-wicket.jar and subclassed the
 WeldApplication and the injected objects in the Wicket WebPage
subclass
 are still null.

 This was from following this example:
 http://docs.jboss.org/weld/reference/1.0.0/en-US/html/viewlayers.html

 If you track down the example code it seems that the examples from
JBoss
 are using older versions of Wicket and Weld/Seam so I don't know if
 something has broken in either project, wicket or weld.

 Injection worked like a charm in a JSF2 controller class so I don't
know
 what going wrong

RE: Wicket and JEE6

2010-03-26 Thread Josh Chappelle
Mark,

Try taking a look at the addComponentInstantiationListener method on the
Application class. It takes one parameter of type
IComponentInstantiationListener and that interface has one method which is
onInstantiation(Component component). Every time a component gets
instantiated it will be handed to this listener so maybe you can write your
own dependency injection code there. I would think that is what the
WeldApplication is doing under the covers but since it isn't working for you
then you may have more luck just writing it yourself. The other trick is to
making this work is obtaining a reference to your weld context. I use Spring
so I'm not familiar with what it takes with Weld.

I hope this helps.

Thanks,

Josh

-Original Message-
From: Ericksen, Mark W (IS) [mailto:mark.erick...@ngc.com] 
Sent: Friday, March 26, 2010 11:52 AM
To: users@wicket.apache.org
Subject: Wicket and JEE6

Hi,

 

I'm building a new java project using all JEE6 technologies.  That means
I'm using JPA, CDI, and JSF2 for example. Each layer came together great
with fully annotated classes until I got to the JSF2 layer which drove
me crazy because JSF wants to mess with HTML element ids and names.   In
looking for alternative view layers I came across Wicket.  The
technology seems great in terms of its philosophy to keep presentation
code separate, except I'm not finding much information about its support
for JEE6 technologies.

 

In particular searches for support for CDI (aka WebBeans, aka Weld) only
got me to an old example in the Seam project.  I cannot find any current
references to using Weld within a Wicket project where I can use
annotations such as @Inject, @Named, @ApplicationScoped, etc.  

 

So my very first question for this list of experts is this:  Is there
currently any support for Weld in Wicket?  Downloading the Weld project
from JBoss, I included the weld-wicket.jar into my project and my
application is subclassed from WeldApplication.  No such luck.  Any
class injected using @Inject is still null.

 

I am using GlassFish v3 which has all the JEE6 goodies included.
Developing with Eclipse.

 

Any help is *greatly* appreciated!

 

-Mark

 

 



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



RE: Wicket and JEE6

2010-03-26 Thread Ericksen, Mark W (IS)
Thanks Josh.  

With your idea in mind I dug deeper into what Weld's support for Wicket
is/was.  
In the Weld download is a jar called weld-wicket.jar that has a
WeldApplication class for doing what you suggest.  However following the
instruction for using their integration code only got me an error when
including their jar in my project.

java.lang.NoSuchMethodError:
org.jboss.weld.Container.services()Lorg/jboss/weld/bootstrap/api/Service
Registry;

So I included the weld-wicket code in my simple project to see what was
going on.  Their integration solution provides a new RequestCycle class
called WeldRequestCycle.  In this class they attempt to preserve a long
running conversation through weld/wicket trickery.  There's a line of
code in a few places that causes a runtime exception that stops the
request cycle.

ConversationContext conversationContext =
Container.instance().services().get(ContextLifecycle.class).getConversat
ionContext();

These are Weld classes, but stepping through the debugger shows it goes
go back through the Wicket filter.  Therefore I don't know who is at
fault here.  Maybe something in Wicket changed that is causing Weld to
croak or Weld in Glassfish is the culprit.  Either way I really don't
care about long running conversation support at this point so I removed
the class and any dependency on it in my modified version of the
weld-wicket code base.

With that exception out of the way and changing my application to
subclass from WeldApplication, I have simple injection working with
Weld.  Yippee!  I'll cross my fingers there are no other side effects.

Problem is now what?  I guess I can post this with the Seam/Weld team
and hope someone updates the Weld-Wicket integration.  Or I can hope
someone from the Wicket team will take a look and see if it's something
in the latest version of Wicket that caused this to break and could do a
patch.

Anyone? :)

-Mark

-Original Message-
From: Josh Chappelle [mailto:jchappe...@4redi.com] 
Sent: Friday, March 26, 2010 2:59 PM
To: users@wicket.apache.org
Subject: RE: Wicket and JEE6

Mark,

Try taking a look at the addComponentInstantiationListener method on the
Application class. It takes one parameter of type
IComponentInstantiationListener and that interface has one method which
is
onInstantiation(Component component). Every time a component gets
instantiated it will be handed to this listener so maybe you can write
your
own dependency injection code there. I would think that is what the
WeldApplication is doing under the covers but since it isn't working for
you
then you may have more luck just writing it yourself. The other trick is
to
making this work is obtaining a reference to your weld context. I use
Spring
so I'm not familiar with what it takes with Weld.

I hope this helps.

Thanks,

Josh

-Original Message-
From: Ericksen, Mark W (IS) [mailto:mark.erick...@ngc.com] 
Sent: Friday, March 26, 2010 11:52 AM
To: users@wicket.apache.org
Subject: Wicket and JEE6

Hi,

 

I'm building a new java project using all JEE6 technologies.  That means
I'm using JPA, CDI, and JSF2 for example. Each layer came together great
with fully annotated classes until I got to the JSF2 layer which drove
me crazy because JSF wants to mess with HTML element ids and names.   In
looking for alternative view layers I came across Wicket.  The
technology seems great in terms of its philosophy to keep presentation
code separate, except I'm not finding much information about its support
for JEE6 technologies.

 

In particular searches for support for CDI (aka WebBeans, aka Weld) only
got me to an old example in the Seam project.  I cannot find any current
references to using Weld within a Wicket project where I can use
annotations such as @Inject, @Named, @ApplicationScoped, etc.  

 

So my very first question for this list of experts is this:  Is there
currently any support for Weld in Wicket?  Downloading the Weld project
from JBoss, I included the weld-wicket.jar into my project and my
application is subclassed from WeldApplication.  No such luck.  Any
class injected using @Inject is still null.

 

I am using GlassFish v3 which has all the JEE6 goodies included.
Developing with Eclipse.

 

Any help is *greatly* appreciated!

 

-Mark

 

 



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket and JEE6

2010-03-26 Thread James Carman
I've got a working example with Weld.  Check out:

http://svn.carmanconsulting.com/public/wicket-candi/trunk

There's a weld-example subdirectory in there.  Currently, I don't have the
conversation stuff working, but the injections appear to be working.
Unfortunately, the implementation doesn't work with OWB. :(  I'll see what's
causing it and see if we can get them both working.  Good luck.

On Fri, Mar 26, 2010 at 6:35 PM, Ericksen, Mark W (IS) 
mark.erick...@ngc.com wrote:

 Thanks Josh.

 With your idea in mind I dug deeper into what Weld's support for Wicket
 is/was.
 In the Weld download is a jar called weld-wicket.jar that has a
 WeldApplication class for doing what you suggest.  However following the
 instruction for using their integration code only got me an error when
 including their jar in my project.
 java.lang.NoSuchMethodError:
 org.jboss.weld.Container.services()Lorg/jboss/weld/bootstrap/api/Service
 Registry;

 So I included the weld-wicket code in my simple project to see what was
 going on.  Their integration solution provides a new RequestCycle class
 called WeldRequestCycle.  In this class they attempt to preserve a long
 running conversation through weld/wicket trickery.  There's a line of
 code in a few places that causes a runtime exception that stops the
 request cycle.

 ConversationContext conversationContext =
 Container.instance().services().get(ContextLifecycle.class).getConversat
 ionContext();

 These are Weld classes, but stepping through the debugger shows it goes
 go back through the Wicket filter.  Therefore I don't know who is at
 fault here.  Maybe something in Wicket changed that is causing Weld to
 croak or Weld in Glassfish is the culprit.  Either way I really don't
 care about long running conversation support at this point so I removed
 the class and any dependency on it in my modified version of the
 weld-wicket code base.

 With that exception out of the way and changing my application to
 subclass from WeldApplication, I have simple injection working with
 Weld.  Yippee!  I'll cross my fingers there are no other side effects.

 Problem is now what?  I guess I can post this with the Seam/Weld team
 and hope someone updates the Weld-Wicket integration.  Or I can hope
 someone from the Wicket team will take a look and see if it's something
 in the latest version of Wicket that caused this to break and could do a
 patch.

 Anyone? :)

 -Mark

 -Original Message-
 From: Josh Chappelle [mailto:jchappe...@4redi.com]
 Sent: Friday, March 26, 2010 2:59 PM
 To: users@wicket.apache.org
 Subject: RE: Wicket and JEE6

 Mark,

 Try taking a look at the addComponentInstantiationListener method on the
 Application class. It takes one parameter of type
 IComponentInstantiationListener and that interface has one method which
 is
 onInstantiation(Component component). Every time a component gets
 instantiated it will be handed to this listener so maybe you can write
 your
 own dependency injection code there. I would think that is what the
 WeldApplication is doing under the covers but since it isn't working for
 you
 then you may have more luck just writing it yourself. The other trick is
 to
 making this work is obtaining a reference to your weld context. I use
 Spring
 so I'm not familiar with what it takes with Weld.

 I hope this helps.

 Thanks,

 Josh

 -Original Message-
 From: Ericksen, Mark W (IS) [mailto:mark.erick...@ngc.com]
 Sent: Friday, March 26, 2010 11:52 AM
 To: users@wicket.apache.org
 Subject: Wicket and JEE6

 Hi,



 I'm building a new java project using all JEE6 technologies.  That means
 I'm using JPA, CDI, and JSF2 for example. Each layer came together great
 with fully annotated classes until I got to the JSF2 layer which drove
 me crazy because JSF wants to mess with HTML element ids and names.   In
 looking for alternative view layers I came across Wicket.  The
 technology seems great in terms of its philosophy to keep presentation
 code separate, except I'm not finding much information about its support
 for JEE6 technologies.



 In particular searches for support for CDI (aka WebBeans, aka Weld) only
 got me to an old example in the Seam project.  I cannot find any current
 references to using Weld within a Wicket project where I can use
 annotations such as @Inject, @Named, @ApplicationScoped, etc.



 So my very first question for this list of experts is this:  Is there
 currently any support for Weld in Wicket?  Downloading the Weld project
 from JBoss, I included the weld-wicket.jar into my project and my
 application is subclassed from WeldApplication.  No such luck.  Any
 class injected using @Inject is still null.



 I am using GlassFish v3 which has all the JEE6 goodies included.
 Developing with Eclipse.



 Any help is *greatly* appreciated!



 -Mark







 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail