subject:"\[Wicket\-user\] Plan to develop a portal"

 well one more thingi left your site on for a long time and then tried
 doing something and then the wicket orange Page Expired came to me.

I thought this was a necessary evil because of Wicket being
session-based?  Users of this site aren't likely to sit there for
very long, honestly.  Their cart will expire if they leave it sit as
well and that is intentional behavior since it is a stateful session
bean.

 try to make it into something as sleek as your major site :)

Do you mean the parent-site, snakeriverfarms.com?  What do you mean by
sleek, exactly?  If you're referring to the design, I didn't design
either of them and really don't care how they look - we have a
designer here that did both of them and takes care of that.  Is there
something in particular that's not sleek about it?

  On 6/14/06, Vincent Jenks [EMAIL PROTECTED] wrote:
  So, I finally completed our first Wicket experiment - the infamous
  storefront I've been blathering about endlessly:
 
 
 



 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user





___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

On 6/15/06, John Patterson [EMAIL PROTECTED] wrote:
Igor, sorry to turn this into a Spring QA!I understand if you don't want to discuss Spring on this list but it is hard to get an unbiased opinion on theirs.i dont mind but maybe you should spin any future messages into a different thread.
also it is not going to really work comparing pico and spring because spring is sooo much more then just ioc.
I have only briefly looked at Springs IoC and was put off by the amount of configuration XML I would have to write. I use Picocontainer which is very simple to configure in Java alone because it makes lots of default assumptions about how to build an object without me having to specify.
first of all let me say that spring's xml config drives java classes, at least from what i have seen and i havent looked very hard. so if you want to use spring without xml that should be doable. see
GenericApplicationContext.registerBeanDefinition()spring can autowire dependencies just like pico, it would go something like this if you are using xml:bean class=foo.Bar autowire=byType/ analogous to pico setter injection
or bean class=foo.Bar autowire=constructor/ analogous to pico constructor injectionand there you have it. i dont know if semantics are exactly the same but they should be pretty close since there isnt that much playroom. something for you to experiment with.
Do you have any insight about how easily Spring can be configured in comparison to Pico?I could see that the examples were almost exclusively using setter injection but I much prefer to use constructors.
yeah, it seems like setter injection is the preferred way in spring. i guess what setter injection gives you that constructor injection doesnt is the name of the setter itself, so it gives your config more context:
bean ... constructor-arg index=0 ref=dep0/ constructor-arg index=1 ref=dep1//beanthis doesnt convey as much information as
bean property name=userManager ref=dep0/ property name=securityManager ref=dep1//beanand this is what the spring xml configuration is all about. one) it gives you a big overview of how the services are connected - there is a nice eclipse plugin that creates a cool graph from the xml file that gives you a birds eye of the infrastructure of your app - something not really possible to do when configuring in code, and two) the configuration is externalized - these things tend to be the things that would change from deployment to deployment so you really dont want them to be configured in code - ie swapping a HibernateUserDao for a LdapUserDao because one company wants you to hook in to their ldap dir, and this is where setter injection is also very useful ...
bean id=userdao calss=com.foo.user.HibernateUserDaoproperty name=sessionFactory ref=hsf//beanvsbean id=userdao class=
com.foo.user.LdapUserDaoproperty name=server value=foo/property name=username value=user/property name=password value=pass/
/beansee, not only can you switch things out between deployments but you can also configure them. if you wanted this func then you would have to maintain your own property file that ldapdao would have to read, etc, etc. this way things are in a single place.
Also, how easy is it to set up containers that manage objectlife-cycle at different scopes?
i havent used this pattern in a long time and havent tried it with spring so i dont know. creating container from xml file is pretty simple, new FileSystemXmlApplicationContext(
file.xml) is all it takesbut to summarize the whole thing:if you dont care about externalizing your config or having visibility into how things are wired and all you need is ioc then pico is def the way to go. its best of breed for lightweight ioc containers, and the factory interface makes it pretty darn easy to customize how beans are managed inside the container.
if you do want externalizable config (the pico addon projects that provide this kinda suck imho) or you want a good base to build infrastructure for then spring is the way to go. it has a bunch of very well integrated modules that you might not need in the beginning of the project but you might need later like remoting, mail, jmx, jms, aop, event system for services, etc. these modules have saved me a ton of time on more then one occasion when i didnt think id need them but later - woops , and i can drop them in with just a few lines of xml. and having a global overview of how things are wired is also nice i think. i really hate xml, but if you use spring for a while you figure out shortcuts that save you from writing a lot of it. and in
2.0 they have different schemas for different modules which is pretty darn cool, it cuts down on xml and makes the xml itself more domain specific so its much more readable.pfew, this ended up longer then i wanted. i dont know how unbiased this is, i really like spring. on the other hand i have used both so there is something to be said for that. take it anyway you want :)
-Igor

Re: [Wicket-user] Plan to develop a portal

I'm kind of glad we're having this discussion here - it's not really
off-topic since I'm still half-wanting to be convinced that I could
use Spring in this project :D

So, you're saying I don't *have* to wire classes together w/ XML in
Spring but I could use
GenericApplicationContext.registerBeanDefinition() programmatically
instead?  What are the drawbacks (besides the obvious -
externalization.)

I looked into Spring 2.0 yesterday shortly...it looks like they've
done some work to be JPA (EJB 3 persistence) friendly...but I have to
admit I really wasn't crazy about what I was seeing there - just
template support for JPA.

On 6/15/06, Igor Vaynberg [EMAIL PROTECTED] wrote:

 On 6/15/06, John Patterson [EMAIL PROTECTED] wrote:
 
 
  Igor, sorry to turn this into a Spring QA!  I understand if you don't
 want to discuss Spring on this list but it is hard to get an unbiased
 opinion on theirs.


 i dont mind but maybe you should spin any future messages into a different
 thread.

 also it is not going to really work comparing pico and spring because spring
 is sooo much more then just ioc.

 
 
 
  I have only briefly looked at Springs IoC and was put off by the amount of
 configuration XML I would have to write.  I use Picocontainer which is very
 simple to configure in Java alone because it makes lots of default
 assumptions about how to build an object without me having to specify.


 first of all let me say that spring's xml config drives java classes, at
 least from what i have seen and i havent looked very hard. so if you want to
 use spring without xml that should be doable. see
 GenericApplicationContext.registerBeanDefinition()

 spring can autowire dependencies just like pico, it would go something
 like this if you are using xml:

 bean class=foo.Bar autowire=byType/ analogous to pico setter injection

 or

 bean class=foo.Bar autowire=constructor/ analogous to pico constructor
 injection

 and there you have it. i dont know if semantics are exactly the same but
 they should be pretty close since there isnt that much playroom. something
 for you to experiment with.


 
 
 
 
  Do you have any insight about how easily Spring can be configured in
 comparison to Pico?  I could see that the examples were almost exclusively
 using setter injection but I much prefer to use constructors.


 yeah, it seems like setter injection is the preferred way in spring. i guess
 what setter injection gives you that constructor injection doesnt is the
 name of the setter itself, so it gives your config more context:

 bean ...
constructor-arg index=0 ref=dep0/
constructor-arg index=1 ref=dep1/
 /bean

 this doesnt convey as much information as

 bean 
property name=userManager ref=dep0/
property name=securityManager ref=dep1/
 /bean

 and this is what the spring xml configuration is all about. one) it gives
 you a big overview of how the services are connected - there is a nice
 eclipse plugin that creates a cool graph from the xml file that gives you a
 birds eye of the infrastructure of your app - something not really possible
 to do when configuring in code, and two) the configuration is externalized -
 these things tend to be the things that would change from deployment to
 deployment so you really dont want them to be configured in code - ie
 swapping a HibernateUserDao for a LdapUserDao because one company wants you
 to hook in to their ldap dir, and this is where setter injection is also
 very useful ...

 bean id=userdao calss=com.foo.user.HibernateUserDao
 property name=sessionFactory ref=hsf/
 /bean

 vs

 bean id=userdao class= com.foo.user.LdapUserDao
 property name=server value=foo/
 property name=username value=user/
 property name=password value=pass/
 /bean

 see, not only can you switch things out between deployments but you can also
 configure them. if you wanted this func then you would have to maintain your
 own property file that ldapdao would have to read, etc, etc. this way things
 are in a single place.


 
 
 
 
 
  Also, how easy is it to set up containers that manage object life-cycle at
 different scopes?


 i havent used this pattern in a long time and havent tried it with spring so
 i dont know. creating container from xml file is pretty simple, new
 FileSystemXmlApplicationContext( file.xml) is all it
 takes

 but to summarize the whole thing:

 if you dont care about externalizing your config or having visibility into
 how things are wired and all you need is ioc then pico is def the way to go.
 its best of breed for lightweight ioc containers, and the factory interface
 makes it pretty darn easy to customize how beans are managed inside the
 container.

 if you do want externalizable config (the pico addon projects that provide
 this kinda suck imho) or you want a good base to build infrastructure for
 then spring is the way to go. it has a bunch of very well integrated modules
 that you might not need in the beginning of the project but you might need
 later like

Re: [Wicket-user] Plan to develop a portal

2006-06-15 Thread John Patterson

Cheers Igor, that has really put things into perspective.  The lack of decent documentation for Pico means that I have spent countless hours getting things to work the way I want.  I suspect that I might switch to Spring when I get some time.John.On 15 Jun 2006, at 13:17, Igor Vaynberg wrote:On 6/15/06, Vincent Jenks [EMAIL PROTECTED] wrote: I'm kind of glad we're having this discussion here - it's not reallyoff-topic since I'm still half-wanting to be convinced that I coulduse Spring in this project :Dwhy would you want to be convinced? :) So, you're saying I don't *have* to wire classes together w/ XML inSpring but I could use GenericApplicationContext.registerBeanDefinition() programmaticallyinstead?  What are the drawbacks (besides the obvious -externalization.)none, its the same thing as the xml config, in fact thats probably what the xml reader calls.  I looked into Spring 2.0 yesterday shortly...it looks like they'vedone some work to be JPA (EJB 3 persistence) friendly...but I have to admit I really wasn't crazy about what I was seeing there - just"template" support for JPA.i dont know, i would use hibernate. it is evolving at a higher velocity then the spec and it has features i miss like the criteria api and custom types. the idea of running an application server just to get persistence sickens me. i havent checked out spring's jpa stuff either btw.  -Igor___Wicket-user mailing listWicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user ___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

 why would you want to be convinced? :)

Because I *am* interested in trying it in a new project but I guess
I'm bull-headed and stubborn...and I'm not entirely convinced it's
useful enough yet.

 i dont know, i would use hibernate. it is evolving at a higher velocity then
 the spec and it has features i miss like the criteria api and custom types.

It is, but that can be both a blessing and a curse - you're sure to
have long-term compatibility with the spec.  I miss the Criteria API
myself, I was mildly disappointed when I learned that EJB3 wouldn't
have it.  However, there have been plenty of cases in my own projects
where the Criteria API was clumsy and unsuited for the task compared
to HQL.  I could not say the same for HQL vs Criteria API in
reverse...I haven't found an instance where HQL/EJB-QL (in EJB3) was
awkward, leaving me with a need for Critiera-style queries.

 the idea of running an application server just to get persistence sickens
 me.

Wow!  Why?  I was using Tomcat before working on these EJB3 projects
and moving to JBoss 4.0.x...and I can't say I've seen a drawback.  On
the contrary - it's nice to have all of the services available to me
when I want or need them (sound familiar ;)  In addition to
persistence I'm using the Timer service, Transactions, JAX-WS, and
moreand if I want it I have simple clustering, messaging
(MDBs)...and all the other features I'm either not using or even aware
of.  I think JBoss is slowly changing people's perceptions that a
container is a huge dump truck and everything else is a Ferrari.

Also, my boss likes to blow a lot of money on support contracts - I
figured we'd always have that opportunity here.


___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

It is, but that can be both a blessing and a curse - you're sure tohave long-term compatibility with the spec.I miss the Criteria API
myself, I was mildly disappointed when I learned that EJB3 wouldn'thave it.However, there have been plenty of cases in my own projectswhere the Criteria API was clumsy and unsuited for the task comparedto HQL.I could not say the same for HQL vs Criteria API in
reverse...I haven't found an instance where HQL/EJB-QL (in EJB3) wasawkward, leaving me with a need for Critiera-style queries.point is, its nice to have the option. and there are plenty cases where criteria api is much more readable then hql, not to mention it is much easier to build search queries, etc instead of using a whole lot of nasty string concatenations. where 1=1 look familliar? :)
Wow!Why?I was using Tomcat before working on these EJB3 projectsand moving to JBoss
4.0.x...and I can't say I've seen a drawback.Onthe contrary - it's nice to have all of the services available to mewhen I want or need them (sound familiar ;)In addition topersistence I'm using the Timer service, Transactions, JAX-WS, and
moreand if I want it I have simple clustering, messaging(MDBs)...and all the other features I'm either not using or even awareof.I think JBoss is slowly changing people's perceptions that acontainer is a huge dump truck and everything else is a Ferrari.
because jetty+spring starts up in like 20 seconds (thats with spring creating all the beans on startup for me), jboss takes more then a minute just for itself. thats a lot of waiting for me every time hotswap cant cope. and last time i checked configuring jboss not to start some of the things i dont need is a nightmare, i tried in the past a few times and a few hours into it gave up. plus i dont need to deal with any of the stupid descriptor files, etc.
web.xml and spring.xml is all i need and they are all simple. and no weird classloader issues, etc. its just a simpler development environment that saves you lots of time, and if you want to deploy on jboss for prod there is nothing stopping you.
Also, my boss likes to blow a lot of money on support contracts - Ifigured we'd always have that opportunity here.
was that a pro or a con? :)-Igor
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

 point is, its nice to have the option. and there are plenty cases where
 criteria api is much more readable then hql, not to mention it is much
 easier to build search queries, etc instead of using a whole lot of nasty
 string concatenations.  where 1=1  look familliar? :)

Sure does! :)  And agreed, I wish they would have included the Criteria API.

 because jetty+spring starts up in like 20 seconds (thats with spring
 creating all the beans on startup for me), jboss takes more then a minute
 just for itself. thats a lot of waiting for me every time hotswap cant cope.
 and last time i checked configuring jboss not to start some of the things i
 dont need is a nightmare, i tried in the past a few times and a few hours
 into it gave up. plus i dont need to deal with any of the stupid descriptor
 files, etc. web.xml and spring.xml is all i need and they are all simple.
 and no weird classloader issues, etc. its just a simpler development
 environment that saves you lots of time, and if you want to deploy on jboss
 for prod there is nothing stopping you.

Honestly, I haven't had these problems so I can't relate.  JBoss
4.0.4.GA starts in about 20-30 seconds and deploying the apps I've
built takes 3-5 sec. roughly.  The only descriptor file I've had to
use so far is a one-liner that maps the URL of the web app to the EAR
app.  You're right, however, you would always deploy-up to JBoss if
needed but probably not deploy-down from JBoss to a servlet/JSP
container simply because those services wouldn't be available.

 was that a pro or a con? :)

Obviously that depends on who you ask :D  You could probably imagine
my opinion on this.


___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

Honestly, I haven't had these problems so I can't relate.JBoss
4.0.4.GA starts in about 20-30 seconds and deploying the apps I'vebuilt takes 3-5 sec. roughly.The only descriptor file I've had touse so far is a one-liner that maps the URL of the web app to the EARapp.You're right, however, you would always deploy-up to JBoss if
needed but probably not deploy-down from JBoss to a servlet/JSPcontainer simply because those services wouldn't be available.well, maybe you have an extremely fast system :) or maybe i am not a very patient person and go for the solution that takes the least time to startup even though the difference might be marginal. 
try the wicket-phonebook in contrib and see how fast that starts up. phonebook has persistence+transactions. id be interested to know how fast it is on your system.-Igor
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

Well, on my dev machine (my laptop) it's a single cpu 2ghz, 2gb ram.
The production server is a dual 3ghz w/ HT proc w/ 4gb ram.  Deploying
to production takes about 2-3 secondsit's a blip on the radar.

I'll give the phonebook app a test and let you know.

On 6/15/06, Igor Vaynberg [EMAIL PROTECTED] wrote:


  Honestly, I haven't had these problems so I can't relate.  JBoss
  4.0.4.GA starts in about 20-30 seconds and deploying the apps I've
  built takes 3-5 sec. roughly.  The only descriptor file I've had to
  use so far is a one-liner that maps the URL of the web app to the EAR
  app.  You're right, however, you would always deploy-up to JBoss if
  needed but probably not deploy-down from JBoss to a servlet/JSP
  container simply because those services wouldn't be available.


 well, maybe you have an extremely fast system :) or maybe i am not a very
 patient person and go for the solution that takes the least time to startup
 even though the difference might be marginal.

 try the wicket-phonebook in contrib and see how fast that starts up.
 phonebook has persistence+transactions. id be interested to know how fast it
 is on your system.

 -Igor




 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user





___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

yeah, but its not just the deployment time, its also the server startup time, or do you never shutdown the server as you are developing/recompiling/etc ?-IgorOn 6/15/06, 
Vincent Jenks [EMAIL PROTECTED] wrote:
Well, on my dev machine (my laptop) it's a single cpu 2ghz, 2gb ram.The production server is a dual 3ghz w/ HT proc w/ 4gb ram.Deployingto production takes about 2-3 secondsit's a blip on the radar.I'll give the phonebook app a test and let you know.
On 6/15/06, Igor Vaynberg [EMAIL PROTECTED] wrote:  Honestly, I haven't had these problems so I can't relate.JBoss  
4.0.4.GA starts in about 20-30 seconds and deploying the apps I've  built takes 3-5 sec. roughly.The only descriptor file I've had to  use so far is a one-liner that maps the URL of the web app to the EAR
  app.You're right, however, you would always deploy-up to JBoss if  needed but probably not deploy-down from JBoss to a servlet/JSP  container simply because those services wouldn't be available.
 well, maybe you have an extremely fast system :) or maybe i am not a very patient person and go for the solution that takes the least time to startup even though the difference might be marginal.
 try the wicket-phonebook in contrib and see how fast that starts up. phonebook has persistence+transactions. id be interested to know how fast it is on your system. -Igor
 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net 
https://lists.sourceforge.net/lists/listinfo/wicket-user___Wicket-user mailing list
Wicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user

___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

2006-06-15 Thread Eelco Hillenius

Igor is a Spring kiddie. ;)

 also it is not going to really work comparing pico and spring because spring
 is sooo much more then just ioc.


___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

2006-06-15 Thread Eelco Hillenius

What about all those nice OSGi alternatives out there? They have some
pretty neat projects going on, and certainly for a portlet like
environment, the plugin model is nice.

Eelco


On 6/14/06, Vincent Jenks [EMAIL PROTECTED] wrote:
 and for a portal this xml you /will/ want to have
  configurable at deployment time in order to configure what portlets/services
  are available to the portal - so even with ejb3 this kind of stuff still has
  to be in some external config.

 I was actually thinking about that the other day...you're absolutely
 right on that point, it has to be externalized somehow.

 I don't see how Spring couldn't be used to compliment EJB 3.0 in the
 regard.  Spring could be used to externalize modular resources, i.e.
 portlets whereas EJB3 could do what it does best...persistence and
 simple transaction demarcation.


 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user



___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

yep, osgi would be pretty cool. deploy/undeploy portlets at runtime can be interesting - something that cannot be done with either ejb3 or spring. but what about integration? that might be a bit more difficult to achieve because servlet container and pretty much everything else has to live inside osgi to deal with the classloaders afaik. im not an expert, but thats the impression i got. you dont integrate things with osgi, you integrate them into it.
for something like this i would just like to have it in a jar and drop it into any app i have and have it work.-IgorOn 6/14/06, Eelco Hillenius
[EMAIL PROTECTED] wrote:
What about all those nice OSGi alternatives out there? They have somepretty neat projects going on, and certainly for a portlet likeenvironment, the plugin model is nice.EelcoOn 6/14/06, Vincent Jenks
[EMAIL PROTECTED] wrote: and for a portal this xml you /will/ want to have configurable at deployment time in order to configure what portlets/services
are available to the portal - so even with ejb3 this kind of stuff still has to be in some external config. I was actually thinking about that the other day...you're absolutely
right on that point, it has to be externalized somehow. I don't see how Spring couldn't be used to compliment EJB 3.0 in the regard.Spring could be used to externalize modular resources, i.e
. portlets whereas EJB3 could do what it does best...persistence and simple transaction demarcation. ___ Wicket-user mailing list
Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

2006-06-15 Thread Gwyn Evans

Worth reminding people that your wicket-phonebook[1] demo's an example
of Spring, as well as Hibernate/Ibatis?

Regarding Jetty, see [2]if anyone wants to go with Jetty6 rather than Jetty4.
/Gwyn

[1] - http://wicket-stuff.sourceforge.net/wicket-phonebook/
[2] - http://www.wicket-wiki.org.uk/wiki/index.php/Jetty6_testing

On 14/06/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
 not to mention the decorator pattern is used a lot in spring and for that
 you also need interfaces.

 -Igor



 On 6/14/06, Igor Vaynberg  [EMAIL PROTECTED] wrote:
 
 
 
  On 6/14/06, Vincent Jenks [EMAIL PROTECTED] wrote:
 
   I guess I avoid it because it appears to force you into thinking in an
   IoC way and I don't like the idea of configuring my classes w/ XML and
   using interfaces for *everything* - sometimes that's just more complex
   than the problem at hand.
 
 
 
  this is a common misconception, you do not need to use interfaces for
 everything. spring handles beans not backed by interface via cglib when they
 need to be proxied for aop/transactions.
 
  a good portion of things you declare in the spring container are the
 things that are going to vary from deployment to deployment - and for those
 things you need to have an interface that is backed by multiple
 implementations, otherwise it wont work. likewise in spring code itself
 there are multiple implementations for most things - that is why the spring
 code has a lot of interfaces.
 
 
  -Igor
 
 




 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user





___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

2006-06-15 Thread Eelco Hillenius

On 6/15/06, Vincent Jenks [EMAIL PROTECTED] wrote:
  well one more thingi left your site on for a long time and then tried
  doing something and then the wicket orange Page Expired came to me.

 I thought this was a necessary evil because of Wicket being
 session-based?  Users of this site aren't likely to sit there for
 very long, honestly.  Their cart will expire if they leave it sit as
 well and that is intentional behavior since it is a stateful session
 bean.

Depends. True for inheritely stateful things like forms. You don't
want/ have to support users arriving in the middle of a wizard. Otoh,
for things like contact information etc, you never want those links to
expire and want them to be accesible directly (e.g. from a search
engine or bookmark). This is where you would use bookmarkable pages
for.

Eelco


___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

[Wicket-user] Plan to develop a portal

So, I finally completed our first Wicket experiment - the infamous
storefront I've been blathering about endlessly:

http://www.snakeriverfarms.com/ - click the animated gif on the
bottom-left of the page.

I'm hoping it leads to more Wicket-based projects for me here at work
but I've got definite plans of my own - the first of which is a Portal
based on Wicket.

We have a really crappy portal here at work that was quite
expensive...and I'd really like to build something better myself w/
Wicket  EJB 3.0.  As far as I know, there's nothing out there like
that currently, is there?

I was looking at JSR-286 but it looks like it's geared toward JSF, am
I correct?  If that were the case I'd have no interest in conforming
to it - but please correct me if I'm wrong.

I'd like to begin planning it right away but I thought I'd take some
feedback from the good folks behind Wicket first since you've all been
so helpful so far!  I've never built anything quite as modular as a
portal before and I'm not sure where to begin as far as making
portlets dynamically loadable  modular while keeping performance
acceptable.  I'd like to build an initial, rough, alpha-quality base
to release as an open source project and work from there.

I've never created my own open source project either, so any input
there would be helpful!

Thanks all!

-v


___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

i think wicket would solve a ton of difficult problems with building portals as long as you portlets are all wicket based :)IPortletFactory { UUID getUUID(), String getName(), Portlet newPortlet(PortletState) }
enum PortletState(NORMAL,MAXIMIZED,MINIMIZED,EDIT)class Portlet extends Panelthen drop a bunch of these factories where you can discover them, and bam - portal :)but seriouslybuilding a portal is a pretty large task, there are a lot of services the portal provides that are non trivial - such as user identity, security, etc, etc
but like i said - if you only want to support wicket-based portlets that confirm to your spec it shouldnt be too difficultsetting up your own os project isnt a big deal, just register it with 
sf.net and you are good to know. if you dont want to deal with that right now we would be happy to create wicket-contrib-portal for you in wicket-stuff so you can get started quickly and when you are ready you can move to a location of your choosing. the advantage of starting out in wicket-stuff is that you can benefit from all the devels who already have access to it ( if you want that of course :) )
-IgorOn 6/14/06, Vincent Jenks [EMAIL PROTECTED] wrote:
So, I finally completed our first Wicket experiment - the infamousstorefront I've been blathering about endlessly:http://www.snakeriverfarms.com/ - click the animated gif on the
bottom-left of the page.I'm hoping it leads to more Wicket-based projects for me here at workbut I've got definite plans of my own - the first of which is a Portalbased on Wicket.We have a really crappy portal here at work that was quite
expensive...and I'd really like to build something better myself w/Wicket  EJB 3.0.As far as I know, there's nothing out there likethat currently, is there?I was looking at JSR-286 but it looks like it's geared toward JSF, am
I correct?If that were the case I'd have no interest in conformingto it - but please correct me if I'm wrong.I'd like to begin planning it right away but I thought I'd take somefeedback from the good folks behind Wicket first since you've all been
so helpful so far!I've never built anything quite as modular as aportal before and I'm not sure where to begin as far as makingportlets dynamically loadable  modular while keeping performance
acceptable.I'd like to build an initial, rough, alpha-quality baseto release as an open source project and work from there.I've never created my own open source project either, so any inputthere would be helpful!
Thanks all!-v___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

 i think wicket would solve a ton of difficult problems with building portals
 as long as you portlets are all wicket based :)

Absolutely!  That was the plan...I wouldn't *dream* of using another
framework! :D

 IPortletFactory { UUID getUUID(), String getName(), Portlet
 newPortlet(PortletState) }

 enum PortletState(NORMAL,MAXIMIZED,MINIMIZED,EDIT)

 class Portlet extends Panel

 then drop a bunch of these factories where you can discover them, and bam -
 portal :)

Wow!  Sounds like I could crank this thing out in 24 hrs. and knock
the big-wigs right out of the market.  Look out Oracle, CA, Microsoft
- the jig is up! ;)

 but seriously
 building a portal is a pretty large task, there are a lot of services the
 portal provides that are non trivial - such as user identity, security, etc,
 etc

I'll start small, naturally, and get something built that lets users
build pages...basically.  However, you're right - these services are
exactly what we have in our turd-portal and would be a requirement at
some phase.

 setting up your own os project isnt a big deal, just register it with sf.net
 and you are good to know. if you dont want to deal with that right now we
 would be happy to create wicket-contrib-portal for you in wicket-stuff so
 you can get started quickly and when you are ready you can move to a
 location of your choosing. the advantage of starting out in wicket-stuff is
 that you can benefit from all the devels who already have access to it ( if
 you want that of course :) )

I think I'd actually like it to start out as a wicket-stuff project
simply because the emphasis will be so heavy on the Wicket side and
like you said, I'd have better guidance.  Sort of like an incubator
project...for lack of a better description.

I've obviously got a lot of learning to do on the internals of Wicket
seeing as I've only built two fairly small applications with it in the
last couple of months.  I'd be using this as a project to further my
hands-on experience.  I'm also relatively new to Java, Hibernate,
EJB3, etc. having only used all of this stuff for  1 yr.

However, I think it'd be a great project and from what I've seen
available in portals out there, Wicket would give me enough leverage
to create something really competitive.



 On 6/14/06, Vincent Jenks [EMAIL PROTECTED] wrote:
 
  So, I finally completed our first Wicket experiment - the infamous
 storefront I've been blathering about endlessly:

 http://www.snakeriverfarms.com/ - click the animated gif on the
 bottom-left of the page.

 I'm hoping it leads to more Wicket-based projects for me here at work
 but I've got definite plans of my own - the first of which is a Portal
 based on Wicket.

 We have a really crappy portal here at work that was quite
 expensive...and I'd really like to build something better myself w/
 Wicket  EJB 3.0.  As far as I know, there's nothing out there like
 that currently, is there?

 I was looking at JSR-286 but it looks like it's geared toward JSF, am
 I correct?  If that were the case I'd have no interest in conforming
 to it - but please correct me if I'm wrong.

 I'd like to begin planning it right away but I thought I'd take some
 feedback from the good folks behind Wicket first since you've all been
 so helpful so far!  I've never built anything quite as modular as a
 portal before and I'm not sure where to begin as far as making
 portlets dynamically loadable  modular while keeping performance
 acceptable.  I'd like to build an initial, rough, alpha-quality base
 to release as an open source project and work from there.

 I've never created my own open source project either, so any input
 there would be helpful!

 Thanks all!

 -v


 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user




 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user





___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

Thanks!  Sure, I'd be happy to.

On 6/14/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
 erm, pressend send too quick

 congrats on the site

 mind adding something here:
 http://www.wicket-wiki.org.uk/wiki/index.php/Stories :)

  -Igor



 On 6/14/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
 
  i think wicket would solve a ton of difficult problems with building
 portals as long as you portlets are all wicket based :)
 
  IPortletFactory { UUID getUUID(), String getName(), Portlet
 newPortlet(PortletState) }
 
  enum PortletState(NORMAL,MAXIMIZED,MINIMIZED,EDIT)
 
  class Portlet extends Panel
 
  then drop a bunch of these factories where you can discover them, and bam
 - portal :)
 
  but seriously
  building a portal is a pretty large task, there are a lot of services the
 portal provides that are non trivial - such as user identity, security, etc,
 etc
 
  but like i said - if you only want to support wicket-based portlets that
 confirm to your spec it shouldnt be too difficult
 
  setting up your own os project isnt a big deal, just register it with
 sf.net and you are good to know. if you dont want to deal with that right
 now we would be happy to create wicket-contrib-portal for you in
 wicket-stuff so you can get started quickly and when you are ready you can
 move to a location of your choosing. the advantage of starting out in
 wicket-stuff is that you can benefit from all the devels who already have
 access to it ( if you want that of course :) )
 
 
  -Igor
 
 
 
 
 
  On 6/14/06, Vincent Jenks  [EMAIL PROTECTED] wrote:
   So, I finally completed our first Wicket experiment - the infamous
   storefront I've been blathering about endlessly:
  
   http://www.snakeriverfarms.com/ - click the animated gif on the
   bottom-left of the page.
  
   I'm hoping it leads to more Wicket-based projects for me here at work
   but I've got definite plans of my own - the first of which is a Portal
   based on Wicket.
  
   We have a really crappy portal here at work that was quite
   expensive...and I'd really like to build something better myself w/
   Wicket  EJB 3.0.  As far as I know, there's nothing out there like
   that currently, is there?
  
   I was looking at JSR-286 but it looks like it's geared toward JSF, am
   I correct?  If that were the case I'd have no interest in conforming
   to it - but please correct me if I'm wrong.
  
   I'd like to begin planning it right away but I thought I'd take some
   feedback from the good folks behind Wicket first since you've all been
   so helpful so far!  I've never built anything quite as modular as a
   portal before and I'm not sure where to begin as far as making
   portlets dynamically loadable  modular while keeping performance
   acceptable.  I'd like to build an initial, rough, alpha-quality base
   to release as an open source project and work from there.
  
   I've never created my own open source project either, so any input
   there would be helpful!
  
   Thanks all!
  
   -v
  
  
   ___
   Wicket-user mailing list
   Wicket-user@lists.sourceforge.net
  
 https://lists.sourceforge.net/lists/listinfo/wicket-user
  
 
 




 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user





___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

I think I'd actually like it to start out as a wicket-stuff projectsimply because the emphasis will be so heavy on the Wicket side and
like you said, I'd have better guidance.Sort of like an incubatorproject...for lack of a better description.thats pretty much what wicket-stuff is anyways - an incubator.
go ahead and create a sf.net user (if you dont have one already) and email me the name so i can add you as a committer to wicket-stuff. from there all you have to do is create the project skeleton, check it in, and you are ready to go. 
However, I think it'd be a great project and from what I've seenavailable in portals out there, Wicket would give me enough leverage
to create something really competitive.if you are talking about being competetive with other large portals that support the jsr then probably not unless you also create the jsr interoperability - which with a wicket event model is silly because wicket makes things much cleaner. but thats up to you.
-Igor
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

  go ahead and create a sf.net user (if you dont have one already) and email
 me the name so i can add you as a committer to wicket-stuff. from there all
 you have to do is create the project skeleton, check it in, and you are
 ready to go.

I think I already am, actually?  I talked to Eelco some time back
about contributing the blogger app I wrote in Wicket  EJB3 but have
not yet had time to commit it.  I believe my user is vjenks.

 if you are talking about being competetive with other large portals that
 support the jsr then probably not unless you also create the jsr
 interoperability - which with a wicket event model is silly because wicket
 makes things much cleaner. but thats up to you.
  -Igor

Agreed - I'm honestly not concerned with supporting the portlets JSR,
I don't see the benefit outside of being able to claim
interoperability - and what good is it if it's that much more
complicated to develop against.  I was thinking more along the lines
of feature-competitive rather than standards.  Once it's pluggable,
if it's easy to develop against and open source, who knows what might
become of it?


___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

I think I already am, actually?I talked to Eelco some time backabout contributing the blogger app I wrote in Wicket  EJB3 but have
not yet had time to commit it.I believe my user is vjenks.yep, you are on there
Agreed - I'm honestly not concerned with supporting the portlets JSR,I don't see the benefit outside of being able to claiminteroperability - and what good is it if it's that much morecomplicated to develop against.I was thinking more along the lines
of feature-competitive rather than standards.Once it's pluggable,if it's easy to develop against and open source, who knows what mightbecome of it?agreed, and i might be interested in contributing to this also. but that depends on the stack you choose. i like spring+hibernate because it is more lightweight and can run off jetty and spring provides a better ioc container then ejb3 which might be important for autodiscovery/plugins architecture. but this is just talk :)
-Igor
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

 agreed, and i might be interested in contributing to this also. but that
 depends on the stack you choose. i like spring+hibernate because it is more
 lightweight and can run off jetty and spring provides a better ioc container
 then ejb3 which might be important for autodiscovery/plugins architecture.
 but this is just talk :)

I'm familiar w/ Hibernate but unfortunately, know very little about
Spring and know nothing about Jetty.  I looked into Spring when I
first started using Hibernate because I hated manually juggling the
Hibernate Session/Transaction...apparently Spring has an elegant
solution through templates?  I was turned off by the amount of XML
required in Spring (and Hibernate) and that's what drove me to
appreciate EJB 3.0 - particularly JBoss.

You do make a good point about IOC, however, since portlets would need
to be very loosely coupled and Spring might remove a great deal of
that complexity.

Isn't the next version of Spring moving a great deal of the XML
necessary to annotations?  I don't follow Spring but I thought I had
read that somewhere?

Injection of resources in EJB3 is pretty slick even if it is lacking,
compared to Spring.


___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

the cause of most xml in spring has always been the transaction demarcation support, but that has already been in annotations for a while so really the xml is minimal. and for a portal this xml you /will/ want to have configurable at deployment time in order to configure what portlets/services are available to the portal - so even with ejb3 this kind of stuff still has to be in some external config.
-IgorOn 6/14/06, Vincent Jenks [EMAIL PROTECTED] wrote:
 agreed, and i might be interested in contributing to this also. but that depends on the stack you choose. i like spring+hibernate because it is more lightweight and can run off jetty and spring provides a better ioc container
 then ejb3 which might be important for autodiscovery/plugins architecture. but this is just talk :)I'm familiar w/ Hibernate but unfortunately, know very little aboutSpring and know nothing about Jetty.I looked into Spring when I
first started using Hibernate because I hated manually juggling theHibernate Session/Transaction...apparently Spring has an elegantsolution through templates?I was turned off by the amount of XMLrequired in Spring (and Hibernate) and that's what drove me to
appreciate EJB 3.0 - particularly JBoss.You do make a good point about IOC, however, since portlets would needto be very loosely coupled and Spring might remove a great deal ofthat complexity.Isn't the next version of Spring moving a great deal of the XML
necessary to annotations?I don't follow Spring but I thought I hadread that somewhere?Injection of resources in EJB3 is pretty slick even if it is lacking,compared to Spring.___
Wicket-user mailing listWicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user

___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

2006-06-14 Thread Eelco Hillenius

 I'm familiar w/ Hibernate but unfortunately, know very little about
 Spring and know nothing about Jetty.  I looked into Spring when I
 first started using Hibernate because I hated manually juggling the
 Hibernate Session/Transaction...apparently Spring has an elegant
 solution through templates?

imvho hibernate templates are not elegant at all. The transaction
management with Spring is a plus though.

Unfortunately, the JBoss/ Seam guys seems to have made Seam (and that
JSR they are submitting) tightly coupled to JSF. That might have made
a nice alternative. Maybe.

Eelco


___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

but you dont need to use spring template to reap the benefits, and you damn well know that since we dont :)-IgorOn 6/14/06, Eelco Hillenius
 [EMAIL PROTECTED] wrote:
 I'm familiar w/ Hibernate but unfortunately, know very little about Spring and know nothing about Jetty.I looked into Spring when I first started using Hibernate because I hated manually juggling the
 Hibernate Session/Transaction...apparently Spring has an elegant solution through templates?imvho hibernate templates are not elegant at all. The transactionmanagement with Spring is a plus though.
Unfortunately, the JBoss/ Seam guys seems to have made Seam (and thatJSR they are submitting) tightly coupled to JSF. That might have madea nice alternative. Maybe.Eelco___
Wicket-user mailing listWicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user

___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

and for a portal this xml you /will/ want to have
 configurable at deployment time in order to configure what portlets/services
 are available to the portal - so even with ejb3 this kind of stuff still has
 to be in some external config.

I was actually thinking about that the other day...you're absolutely
right on that point, it has to be externalized somehow.

I don't see how Spring couldn't be used to compliment EJB 3.0 in the
regard.  Spring could be used to externalize modular resources, i.e.
portlets whereas EJB3 could do what it does best...persistence and
simple transaction demarcation.


___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

spring has simple transaction demarcation, see @Transactional annotation. and as far as persistence if using spring 1.x you can use hibernate with ejb3 annotations, or if using spring 2.x you can use hibernate's entitymanager which is basically ejb3 and they have jpa (or wtf that acronym is) support as well
-IgorOn 6/14/06, Vincent Jenks [EMAIL PROTECTED] wrote:
and for a portal this xml you /will/ want to have configurable at deployment time in order to configure what portlets/services are available to the portal - so even with ejb3 this kind of stuff still has
 to be in some external config.I was actually thinking about that the other day...you're absolutelyright on that point, it has to be externalized somehow.I don't see how Spring couldn't be used to compliment EJB 
3.0 in theregard.Spring could be used to externalize modular resources, i.e.portlets whereas EJB3 could do what it does best...persistence andsimple transaction demarcation.___
Wicket-user mailing listWicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user

___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

2006-06-14 Thread Philip A. Chapman

On Wed, 2006-06-14 at 14:21 -0600, Vincent Jenks wrote:

agreed, and i might be interested in contributing to this also. but that
depends on the stack you choose. i like spring+hibernate because it is more
lightweight and can run off jetty and spring provides a better ioc container
then ejb3 which might be important for autodiscovery/plugins architecture.
but this is just talk :)

I'm familiar w/ Hibernate but unfortunately, know very little about
Spring and know nothing about Jetty. I looked into Spring when I
first started using Hibernate because I hated manually juggling the
Hibernate Session/Transaction...apparently Spring has an elegant
solution through templates? I was turned off by the amount of XML
required in Spring (and Hibernate) and that's what drove me to
appreciate EJB 3.0 - particularly JBoss.

Ivan has shown me how easy it is to develop a wicket app with the wicket+spring+hibernate stack and using jetty for debugging. It's very easy and very fast. The xml required for most tasks is pretty minimal. I'm not a huge fan of xml and would have never bought into spring if using it to manage hibernate required a lot.

Good luck with the portal. I'll keep a close eye on it.

--
Philip A. Chapman

Desktop and Web Application Development:
Java, .NET, PostgreSQL, MySQL, MSSQL
Linux, Windows 2000, Windows XP

signature.asc
Description: This is a digitally signed message part
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

you cut me deep, man.On 6/14/06, Philip A. Chapman [EMAIL PROTECTED] wrote:

On Wed, 2006-06-14 at 14:21 -0600, Vincent Jenks wrote:

Good luck with the portal. I'll keep a close eye on it.

-- Philip A. ChapmanDesktop and Web Application Development:Java, .NET, PostgreSQL, MySQL, MSSQLLinux, Windows 2000, Windows XP

-BEGIN PGP SIGNATURE-Version: GnuPG v1.4.2.2 (GNU/Linux)iD8DBQBEkHU4AdpynRSGw3URAmjcAJ4hHQsCKBkP0AigMV2XrP18ApYgFgCeL39BKnvAWmEnrJp27D3VKk7JUU8==9oi0-END PGP SIGNATURE-
___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

2006-06-14 Thread Matej Knopp

Yeah, with hibernate 3 the HibernateTemplate doesn't really makes much 
sense. With hibernate 2 it was good for translating exceptions, since 
HibernateException was checked.

However, we've been working on a JDBC project lately and Spring's 
JdbcTemplate was a huge win to have.

-Matej

Igor Vaynberg wrote:
 but you dont need to use spring template to reap the benefits, and you 
 damn well know that since we dont :)
 
 -Igor
 
 
 On 6/14/06, *Eelco Hillenius* [EMAIL PROTECTED] 
 mailto:[EMAIL PROTECTED] wrote:
 
   I'm familiar w/ Hibernate but unfortunately, know very little about
   Spring and know nothing about Jetty.  I looked into Spring when I
   first started using Hibernate because I hated manually juggling the
   Hibernate Session/Transaction...apparently Spring has an elegant
   solution through templates?
 
 imvho hibernate templates are not elegant at all. The transaction
 management with Spring is a plus though.
 
 Unfortunately, the JBoss/ Seam guys seems to have made Seam (and that
 JSR they are submitting) tightly coupled to JSF. That might have made
 a nice alternative. Maybe.
 
 Eelco
 
 
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 mailto:Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 
 
 
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user



___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

Perhaps it'd be worth developing a container and non-container based
version of the project...or something in between.  I suppose I'll need
to do my homework first!

Is Spring 2.x moving away from XML?  I just downloaded the M5
reference, I'll flip through it for a bit.

On 6/14/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
 spring has simple transaction demarcation, see @Transactional annotation.
 and as far as persistence if using spring 1.x you can use hibernate with
 ejb3 annotations, or if using spring 2.x you can use hibernate's
 entitymanager which is basically ejb3 and they have jpa (or wtf that acronym
 is) support as well

 -Igor



 On 6/14/06, Vincent Jenks [EMAIL PROTECTED] wrote:
 
  and for a portal this xml you /will/ want to have
  configurable at deployment time in order to configure what
 portlets/services
  are available to the portal - so even with ejb3 this kind of stuff still
 has
  to be in some external config.

 I was actually thinking about that the other day...you're absolutely
 right on that point, it has to be externalized somehow.

 I don't see how Spring couldn't be used to compliment EJB 3.0 in the
 regard.  Spring could be used to externalize modular resources, i.e.
 portlets whereas EJB3 could do what it does best...persistence and
 simple transaction demarcation.


 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user




 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user





___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

they have made some improvements yes. but as i said, if you know what you are doing xml is minimal even in 1.2.6-IgorOn 6/14/06, Vincent Jenks
 [EMAIL PROTECTED] wrote:
Perhaps it'd be worth developing a container and non-container basedversion of the project...or something in between.I suppose I'll needto do my homework first!Is Spring 2.x moving away from XML?I just downloaded the M5
reference, I'll flip through it for a bit.On 6/14/06, Igor Vaynberg [EMAIL PROTECTED] wrote: spring has simple transaction demarcation, see @Transactional annotation.
 and as far as persistence if using spring 1.x you can use hibernate with ejb3 annotations, or if using spring 2.x you can use hibernate's entitymanager which is basically ejb3 and they have jpa (or wtf that acronym
 is) support as well -Igor On 6/14/06, Vincent Jenks [EMAIL PROTECTED] wrote: and for a portal this xml you /will/ want to have
  configurable at deployment time in order to configure what portlets/services  are available to the portal - so even with ejb3 this kind of stuff still has  to be in some external config.
 I was actually thinking about that the other day...you're absolutely right on that point, it has to be externalized somehow. I don't see how Spring couldn't be used to compliment EJB 
3.0 in the regard.Spring could be used to externalize modular resources, i.e. portlets whereas EJB3 could do what it does best...persistence and simple transaction demarcation.
 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net 
https://lists.sourceforge.net/lists/listinfo/wicket-user ___ Wicket-user mailing list 
Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user___
Wicket-user mailing listWicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user

___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

Coincidentally, I came across this article the other day:

http://www.javaworld.com/javaworld/jw-06-2006/jw-0605-obix.html

It seems like Obix has a lot of overlap w/ Spring, no?

On 6/14/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
 they have made some improvements yes. but as i said, if you know what you
 are doing xml is minimal even in 1.2.6

 -Igor



 On 6/14/06, Vincent Jenks [EMAIL PROTECTED] wrote:
 
  Perhaps it'd be worth developing a container and non-container based
 version of the project...or something in between.  I suppose I'll need
 to do my homework first!

 Is Spring 2.x moving away from XML?  I just downloaded the M5
 reference, I'll flip through it for a bit.

 On 6/14/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
  spring has simple transaction demarcation, see @Transactional annotation.
  and as far as persistence if using spring 1.x you can use hibernate with
  ejb3 annotations, or if using spring 2.x you can use hibernate's
  entitymanager which is basically ejb3 and they have jpa (or wtf that
 acronym
  is) support as well
 
  -Igor
 
 
 
  On 6/14/06, Vincent Jenks [EMAIL PROTECTED] wrote:
  
   and for a portal this xml you /will/ want to have
   configurable at deployment time in order to configure what
  portlets/services
   are available to the portal - so even with ejb3 this kind of stuff still
  has
   to be in some external config.
 
  I was actually thinking about that the other day...you're absolutely
  right on that point, it has to be externalized somehow.
 
  I don't see how Spring couldn't be used to compliment EJB 3.0 in the
  regard.  Spring could be used to externalize modular resources, i.e.
  portlets whereas EJB3 could do what it does best...persistence and
  simple transaction demarcation.
 
 
   ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 
 
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 


 ___

 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user




 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user





___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

 Were should I report bugs ;-)

I'll file a report w/ our support staff, stat!  *scibbling 'todo' note
on palm of hand*

 Click on Privacy Policy at the bottom and then SRF icon at the top. I
 get a 404 for the https://secure.abfoodsusa.com/ABCommerce/admin_home

Good find!  It's not like I can get anyone to test around here...

 But else it's nice. Perhaps some bookmarkable pages here and there (like
 the privacy policy), but I'll guess thats just a matter of taste :-P

Yeah...guess I could




 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user



___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

i dont think so. spring is an ioc container at the very least. obix is just a lib to make it easy to read in config files.-IgorOn 6/14/06, Vincent Jenks
 [EMAIL PROTECTED] wrote:
Coincidentally, I came across this article the other day:http://www.javaworld.com/javaworld/jw-06-2006/jw-0605-obix.htmlIt seems like Obix has a lot of overlap w/ Spring, no?
On 6/14/06, Igor Vaynberg [EMAIL PROTECTED] wrote: they have made some improvements yes. but as i said, if you know what you are doing xml is minimal even in 
1.2.6 -Igor On 6/14/06, Vincent Jenks [EMAIL PROTECTED] wrote: Perhaps it'd be worth developing a container and non-container based
 version of the project...or something in between.I suppose I'll need to do my homework first! Is Spring 2.x moving away from XML?I just downloaded the M5 reference, I'll flip through it for a bit.
 On 6/14/06, Igor Vaynberg [EMAIL PROTECTED] wrote:  spring has simple transaction demarcation, see @Transactional annotation.  and as far as persistence if using spring 
1.x you can use hibernate with  ejb3 annotations, or if using spring 2.x you can use hibernate's  entitymanager which is basically ejb3 and they have jpa (or wtf that acronym  is) support as well
   -Igor On 6/14/06, Vincent Jenks [EMAIL PROTECTED] wrote:   and for a portal this xml you /will/ want to have
   configurable at deployment time in order to configure what  portlets/services   are available to the portal - so even with ejb3 this kind of stuff still  has   to be in some external config.
   I was actually thinking about that the other day...you're absolutely  right on that point, it has to be externalized somehow.   I don't see how Spring couldn't be used to compliment EJB 
3.0 in the  regard.Spring could be used to externalize modular resources, i.e.  portlets whereas EJB3 could do what it does best...persistence and  simple transaction demarcation.
   ___  Wicket-user mailing list  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user  ___
  Wicket-user mailing list  Wicket-user@lists.sourceforge.net  
https://lists.sourceforge.net/lists/listinfo/wicket-user___ Wicket-user mailing list 
Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user___Wicket-user mailing list
Wicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user

___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

2006-06-14 Thread Matej Knopp

IOC + AOP + Remoting + Lot of other stuff.
Spring is a swiss army knife of web development :)

-Matej

Igor Vaynberg wrote:
 i dont think so. spring is an ioc container at the very least. obix is 
 just a lib to make it easy to read in config files.
 
 -Igor
 
 
 On 6/14/06, *Vincent Jenks * [EMAIL PROTECTED] 
 mailto:[EMAIL PROTECTED] wrote:
 
 Coincidentally, I came across this article the other day:
 
 http://www.javaworld.com/javaworld/jw-06-2006/jw-0605-obix.html
 
 It seems like Obix has a lot of overlap w/ Spring, no?
 
 On 6/14/06, Igor Vaynberg [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:
   they have made some improvements yes. but as i said, if you know
 what you
   are doing xml is minimal even in 1.2.6
  
   -Igor
  
  
  
   On 6/14/06, Vincent Jenks [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:
   
Perhaps it'd be worth developing a container and non-container
 based
   version of the project...or something in between.  I suppose I'll
 need
   to do my homework first!
  
   Is Spring 2.x moving away from XML?  I just downloaded the M5
   reference, I'll flip through it for a bit.
  
   On 6/14/06, Igor Vaynberg [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:
spring has simple transaction demarcation, see @Transactional
 annotation.
and as far as persistence if using spring 1.x you can use
 hibernate with
ejb3 annotations, or if using spring 2.x you can use hibernate's
entitymanager which is basically ejb3 and they have jpa (or wtf
 that
   acronym
is) support as well
   
-Igor
   
   
   
On 6/14/06, Vincent Jenks [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:

 and for a portal this xml you /will/ want to have
 configurable at deployment time in order to configure what
portlets/services
 are available to the portal - so even with ejb3 this kind of
 stuff still
has
 to be in some external config.
   
I was actually thinking about that the other day...you're
 absolutely
right on that point, it has to be externalized somehow.
   
I don't see how Spring couldn't be used to compliment EJB 3.0
 in the
regard.  Spring could be used to externalize modular resources,
 i.e.
portlets whereas EJB3 could do what it does best...persistence and
simple transaction demarcation.
   
   
 ___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
 mailto:Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
   
   
   
   
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
 mailto:Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
   
   
   
  
  
   ___
  
   Wicket-user mailing list
   Wicket-user@lists.sourceforge.net
 mailto:Wicket-user@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/wicket-user
  
  
  
  
   ___
   Wicket-user mailing list
   Wicket-user@lists.sourceforge.net
 mailto:Wicket-user@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/wicket-user
  
  
  
 
 
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 mailto:Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 
 
 
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user



___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

yeah, but once again, you only use the parts you want to use. but it is nice to have the fancy things available and nicely integrated when you do have a need for them.-Igor
On 6/14/06, Matej Knopp [EMAIL PROTECTED] wrote:
IOC + AOP + Remoting + Lot of other stuff.Spring is a swiss army knife of web development :)-MatejIgor Vaynberg wrote: i dont think so. spring is an ioc container at the very least. obix is
 just a lib to make it easy to read in config files. -Igor On 6/14/06, *Vincent Jenks * [EMAIL PROTECTED] mailto:
[EMAIL PROTECTED] wrote: Coincidentally, I came across this article the other day: 
http://www.javaworld.com/javaworld/jw-06-2006/jw-0605-obix.html It seems like Obix has a lot of overlap w/ Spring, no? On 6/14/06, Igor Vaynberg 
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: they have made some improvements yes. but as i said, if you know
 what you are doing xml is minimal even in 1.2.6 -Igor On 6/14/06, Vincent Jenks 
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Perhaps it'd be worth developing a container and non-container
 based version of the project...or something in between.I suppose I'll need to do my homework first! Is Spring 2.x moving away from XML?I just downloaded the M5
 reference, I'll flip through it for a bit. On 6/14/06, Igor Vaynberg [EMAIL PROTECTED] mailto:
[EMAIL PROTECTED] wrote:  spring has simple transaction demarcation, see @Transactional annotation.  and as far as persistence if using spring 1.x you can use
 hibernate with  ejb3 annotations, or if using spring 2.x you can use hibernate's  entitymanager which is basically ejb3 and they have jpa (or wtf that
 acronym  is) support as well   -Igor On 6/14/06, Vincent Jenks 
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:   and for a portal this xml you /will/ want to have
   configurable at deployment time in order to configure what  portlets/services   are available to the portal - so even with ejb3 this kind of
 stuff still  has   to be in some external config.   I was actually thinking about that the other day...you're absolutely
  right on that point, it has to be externalized somehow.   I don't see how Spring couldn't be used to compliment EJB 3.0 in the  regard.Spring could be used to externalize modular resources,
 i.e.  portlets whereas EJB3 could do what it does best...persistence and  simple transaction demarcation.   ___
  Wicket-user mailing list  Wicket-user@lists.sourceforge.net mailto:
Wicket-user@lists.sourceforge.net  https://lists.sourceforge.net/lists/listinfo/wicket-user  
___  Wicket-user mailing list  
Wicket-user@lists.sourceforge.net mailto:Wicket-user@lists.sourceforge.net  
https://lists.sourceforge.net/lists/listinfo/wicket-user___
 Wicket-user mailing list Wicket-user@lists.sourceforge.net mailto:
Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net
 mailto:Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
 ___ Wicket-user mailing list 
Wicket-user@lists.sourceforge.net mailto:Wicket-user@lists.sourceforge.net 
https://lists.sourceforge.net/lists/listinfo/wicket-user  ___
 Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

Right, right, I understand all of that...but the configuration looks
similar...it seems like a good candidate for this portal project for
externalizing resources.  In other words - Spring might be overkill if
it can be done more easily w/ Obix if I were to use EJB3.

I guess I was thinking aloudheh.

On 6/14/06, Matej Knopp [EMAIL PROTECTED] wrote:
 IOC + AOP + Remoting + Lot of other stuff.
 Spring is a swiss army knife of web development :)

 -Matej

 Igor Vaynberg wrote:
  i dont think so. spring is an ioc container at the very least. obix is
  just a lib to make it easy to read in config files.
 
  -Igor
 
 
  On 6/14/06, *Vincent Jenks * [EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED] wrote:
 
  Coincidentally, I came across this article the other day:
 
  http://www.javaworld.com/javaworld/jw-06-2006/jw-0605-obix.html
 
  It seems like Obix has a lot of overlap w/ Spring, no?
 
  On 6/14/06, Igor Vaynberg [EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED] wrote:
they have made some improvements yes. but as i said, if you know
  what you
are doing xml is minimal even in 1.2.6
   
-Igor
   
   
   
On 6/14/06, Vincent Jenks [EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED] wrote:

 Perhaps it'd be worth developing a container and non-container
  based
version of the project...or something in between.  I suppose I'll
  need
to do my homework first!
   
Is Spring 2.x moving away from XML?  I just downloaded the M5
reference, I'll flip through it for a bit.
   
On 6/14/06, Igor Vaynberg [EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED] wrote:
 spring has simple transaction demarcation, see @Transactional
  annotation.
 and as far as persistence if using spring 1.x you can use
  hibernate with
 ejb3 annotations, or if using spring 2.x you can use hibernate's
 entitymanager which is basically ejb3 and they have jpa (or wtf
  that
acronym
 is) support as well

 -Igor



 On 6/14/06, Vincent Jenks [EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED] wrote:
 
  and for a portal this xml you /will/ want to have
  configurable at deployment time in order to configure what
 portlets/services
  are available to the portal - so even with ejb3 this kind of
  stuff still
 has
  to be in some external config.

 I was actually thinking about that the other day...you're
  absolutely
 right on that point, it has to be externalized somehow.

 I don't see how Spring couldn't be used to compliment EJB 3.0
  in the
 regard.  Spring could be used to externalize modular resources,
  i.e.
 portlets whereas EJB3 could do what it does best...persistence and
 simple transaction demarcation.


  ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
  mailto:Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user




 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
  mailto:Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user



   
   
___
   
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
  mailto:Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
   
   
   
   
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
  mailto:Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
   
   
   
 
 
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  mailto:Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 
  
 
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user



 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user



___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal

2006-06-14 Thread Matej Knopp

It depends on what do you need. Spring gives you a lot of flexibility. 
The question is, how much flexibility you need? Spring is little 
difficult to grasp at first.

But I'd certainly not label spring as overkill. You can use only the 
parts you need. In web application it really doesn't matter if you have 
one additional 1.5 megs jar or not.

Quite often you start using spring for basic stuff (IOC, some simple 
AOP) and then you need something more, and you find out that the support 
is already there.

We integrated spring in one project and at some point, we needed to 
publish a service as WebService (but not necessarily SOAP). So I put 
couple of lines to the spring configuration file and the service was 
exported. It haven't taken more than 30 minutes to get it working.

-Matej

Vincent Jenks wrote:
 Right, right, I understand all of that...but the configuration looks
 similar...it seems like a good candidate for this portal project for
 externalizing resources.  In other words - Spring might be overkill if
 it can be done more easily w/ Obix if I were to use EJB3.
 
 I guess I was thinking aloudheh.
 
 On 6/14/06, Matej Knopp [EMAIL PROTECTED] wrote:
 IOC + AOP + Remoting + Lot of other stuff.
 Spring is a swiss army knife of web development :)

 -Matej

 Igor Vaynberg wrote:
 i dont think so. spring is an ioc container at the very least. obix is
 just a lib to make it easy to read in config files.

 -Igor


 On 6/14/06, *Vincent Jenks * [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:

 Coincidentally, I came across this article the other day:

 http://www.javaworld.com/javaworld/jw-06-2006/jw-0605-obix.html

 It seems like Obix has a lot of overlap w/ Spring, no?

 On 6/14/06, Igor Vaynberg [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:
   they have made some improvements yes. but as i said, if you know
 what you
   are doing xml is minimal even in 1.2.6
  
   -Igor
  
  
  
   On 6/14/06, Vincent Jenks [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:
   
Perhaps it'd be worth developing a container and non-container
 based
   version of the project...or something in between.  I suppose I'll
 need
   to do my homework first!
  
   Is Spring 2.x moving away from XML?  I just downloaded the M5
   reference, I'll flip through it for a bit.
  
   On 6/14/06, Igor Vaynberg [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:
spring has simple transaction demarcation, see @Transactional
 annotation.
and as far as persistence if using spring 1.x you can use
 hibernate with
ejb3 annotations, or if using spring 2.x you can use hibernate's
entitymanager which is basically ejb3 and they have jpa (or wtf
 that
   acronym
is) support as well
   
-Igor
   
   
   
On 6/14/06, Vincent Jenks [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:

 and for a portal this xml you /will/ want to have
 configurable at deployment time in order to configure what
portlets/services
 are available to the portal - so even with ejb3 this kind of
 stuff still
has
 to be in some external config.
   
I was actually thinking about that the other day...you're
 absolutely
right on that point, it has to be externalized somehow.
   
I don't see how Spring couldn't be used to compliment EJB 3.0
 in the
regard.  Spring could be used to externalize modular resources,
 i.e.
portlets whereas EJB3 could do what it does best...persistence and
simple transaction demarcation.
   
   
 ___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
 mailto:Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
   
   
   
   
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
 mailto:Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
   
   
   
  
  
   ___
  
   Wicket-user mailing list
   Wicket-user@lists.sourceforge.net
 mailto:Wicket-user@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/wicket-user
  
  
  
  
   ___
   Wicket-user mailing list
   Wicket-user@lists.sourceforge.net
 mailto:Wicket-user@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/wicket-user
  
  
  


 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net

Re: [Wicket-user] Plan to develop a portal

 It depends on what do you need. Spring gives you a lot of flexibility.
 The question is, how much flexibility you need? Spring is little
 difficult to grasp at first.

I don't think it's all that complicated to grasp the concepts but
every time I come around to looking into it I can never really justify
the need for it.  I actually bought a couple of Spring books a few
months back and covered quite a bit of them...

I guess I avoid it because it appears to force you into thinking in an
IoC way and I don't like the idea of configuring my classes w/ XML and
using interfaces for *everything* - sometimes that's just more complex
than the problem at hand.

I hear mostly good things about it but I suppose I'm just not well
educated enough on it to really criticize it...these are just my
initial impressions.

 But I'd certainly not label spring as overkill. You can use only the
 parts you need. In web application it really doesn't matter if you have
 one additional 1.5 megs jar or not.

Sure, I understand that as well...but it's yet another framework to
introduce into my application and I haven't seen the need yet.
Through all of my reading it has never felt like an intuitive, hit
the ground running framework that I could begin using
quickly...there's a bit of a learning curve there.  I meant overkill
as in I've found easy-enough ways to solve problems without Spring -
so far.

 Vincent Jenks wrote:
  Right, right, I understand all of that...but the configuration looks
  similar...it seems like a good candidate for this portal project for
  externalizing resources.  In other words - Spring might be overkill if
  it can be done more easily w/ Obix if I were to use EJB3.
 
  I guess I was thinking aloudheh.
 
  On 6/14/06, Matej Knopp [EMAIL PROTECTED] wrote:
  IOC + AOP + Remoting + Lot of other stuff.
  Spring is a swiss army knife of web development :)
 
  -Matej
 
  Igor Vaynberg wrote:
  i dont think so. spring is an ioc container at the very least. obix is
  just a lib to make it easy to read in config files.
 
  -Igor
 
 
  On 6/14/06, *Vincent Jenks * [EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED] wrote:
 
  Coincidentally, I came across this article the other day:
 
  http://www.javaworld.com/javaworld/jw-06-2006/jw-0605-obix.html
 
  It seems like Obix has a lot of overlap w/ Spring, no?
 
  On 6/14/06, Igor Vaynberg [EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED] wrote:
they have made some improvements yes. but as i said, if you know
  what you
are doing xml is minimal even in 1.2.6
   
-Igor
   
   
   
On 6/14/06, Vincent Jenks [EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED] wrote:

 Perhaps it'd be worth developing a container and non-container
  based
version of the project...or something in between.  I suppose I'll
  need
to do my homework first!
   
Is Spring 2.x moving away from XML?  I just downloaded the M5
reference, I'll flip through it for a bit.
   
On 6/14/06, Igor Vaynberg [EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED] wrote:
 spring has simple transaction demarcation, see @Transactional
  annotation.
 and as far as persistence if using spring 1.x you can use
  hibernate with
 ejb3 annotations, or if using spring 2.x you can use hibernate's
 entitymanager which is basically ejb3 and they have jpa (or wtf
  that
acronym
 is) support as well

 -Igor



 On 6/14/06, Vincent Jenks [EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED] wrote:
 
  and for a portal this xml you /will/ want to have
  configurable at deployment time in order to configure what
 portlets/services
  are available to the portal - so even with ejb3 this kind of
  stuff still
 has
  to be in some external config.

 I was actually thinking about that the other day...you're
  absolutely
 right on that point, it has to be externalized somehow.

 I don't see how Spring couldn't be used to compliment EJB 3.0
  in the
 regard.  Spring could be used to externalize modular resources,
  i.e.
 portlets whereas EJB3 could do what it does best...persistence 
  and
 simple transaction demarcation.


  ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
  mailto:Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user




 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
  mailto:Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Plan to develop a portal