Re: OT: Struts JSR?
Martin Cooper wrote: On Sat, 20 Mar 2004, Nadeem Bitar wrote: On Sat, 2004-03-20 at 17:47 -0500, Ted Husted wrote: On Fri, 19 Mar 2004 18:53:58 -0800, Nadeem Bitar wrote: If for example JSF 2.0 is available, and Spring Framework is well integrated with JSF before Struts 2.0 is available, I strongly believe that struts won't have a place and would lose market shares. First let's be very clear. It's *not* about market share. I have to disagree with you on this one. Struts is the defacto standard because of its market share. It is well documented, it has a healthy community, and struts talent is available easily, because of its market share. I think what Ted is trying to say is that the Struts developers do not work on Struts to increase its market share, but because Struts works for us, and we care to put in the time and effort to maintain and further develop it. The fact that it has become sufficiently popular to turn into a de facto standard is nice, but that's secondary to (most of) us, and not why we're here. -- Martin Cooper Yes. This has been true right from the beginning. Struts does not need market-share to survive. All we need is a community of developers who use the product and want to help support it. A community of developers would support a product only if they believe in it. Many hard core struts users and developers are migrating to other frameworks and this is a loss for the whole community. Struts 2.0 would have a chance to bridge the gap between struts and other frameworks. Since Struts 2.0 is still on the drawing board I am only advocating to do it right even if that means breaking backward compatibility and making major architecture changes. You are right on the target. With the current thinking of either Struts 1.3 or Struts 2.0, i think Struts will be a de-facto standard of web controller for other frameworks and contaiers. BaTien DBGROUPS How many downloads we realize isn't important. Whether 90% or whether 10% of shipping applications use Struts isn't important. What's important is that Struts works well for the people who do want to use it, and that those people want to do the work to make it better. Of course, if we all find that JSF does most of what we all need, and we want to use it in our own applications, then Struts will quickly become whatever other JSF components we need to ship our own applications. But so long as products like JSF leave out components that real-life applications need, there will always be a Struts. From the beginning, it's always been about providing axles between the wheels that Java already has. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] .
Re: Updated Struts-Faces Integration Library
Craig R. McClanahan wrote:
I'm happy to announce the availability of the first nightly build of the
integration library supporting the use of JavaServer Faces and Struts that has
been updated to support the final release of JavaServer Faces 1.0. This is not
a formal Apache release; however, it is intended to support experimentation and
trigger bug reports so that we can complete a release in the next couple of
months. Pick up the files dated 20040308 (or later) from:
http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces/
Key new features (see the README.txt file for full details):
* Supports the final release of JavaServer Faces 1.0 (previous
versions supported the beta version).
* Fully worked out examples with and without Tiles.
* You can use value binding expressions (#{...}) for all attributes
of the Struts specific components, just like you can with all attributes
of standard JavaServer Faces components.
* A managed bean named struts is available to provide access to
Struts-internal objects, similar in spirit to the bean:struts
tag in the existing libraries.
* The integration library supports either prefix mapping (/faces/*)
or extension mapping (*.faces) for the JavaServer Faces servlet.
* You can use the new s:loadMessages tag to expose a Struts
MessageResources object as a Map, so that messages can be looked
up using value binding expressions, similar to the way that the
standard f:loadBundle tag works with resource bundles. This allows
you to use your existing Struts application resources seamlessly with
non-Struts component tags.
Craig McClanahan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
.
Great Craig.
You are amazing. We are working with both Struts-Faces and Struts-Chain.
Thanks
BaTien
DBGROUPS
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does struts-chain work with tomcat 4.1 ?
Patrick Chanezon wrote: Forget about question 3, and the exception. It seems like the struts-config.xml file for the struts-chain does not contain the welcome actionforward definition. diff -U 3 /Users/pat/java/jakarta-tomcat-4.1.29/webapps/struts-chain/WEB-INF/struts-config.xml /Users/pat/java/jakarta-tomcat-4.1.29/webapps/struts-example/WEB-INF/struts-config.xml !-- == Global Forward Definitions == -- global-forwards forward name=logoff path=/logoff.do/ -forward name=logonpath=/logon.jsp/ -forward name=success path=/mainMenu.jsp/ +forward name=logonpath=/logon.do/ +forward name=success path=/mainMenu.do/ +forward name=welcome path=/welcome.do/ /global-forwards I took the struts-config.xml from struts-example and added the chain related configurations and this Exception is not there anymore. Other problems pop up, but not this one :-) My other questions still stand. 1. is someone actively working on that code right now ? Yes, i am working on struts-chain, but in a slightly different direction. To me, struts-chain example is a proof-of-concept. I am still waiting for the codes in struts-jericho to play. Specifically, i start from JavaServer Faces since stateful UIComponents provided by the framework is nice and i expect many complex components will be available either commercially or from open sources. I try to combine best features of different frameworks by playing around with struts-jericho Servlet Request Adapter, Controller and Processor overview. The adding of Command Context as suggested in struts-jericho is important since each command is a service component that is self contained, fully customizable and manageable. BaTien DBGROUPS 2. does someone have struts-chain installed and configured correctly ? from where did you get it ? Any caveats for the build ? 4. I used maven to build struts: the maven dist target's result differs significantly from ant's dist, and contrib/struts-chain makes some assumptions about what's 2 levels above that are not met by the maven build. This is whay I had to use a nightly build. is there a way to generate jakarta-struts's build.properties from maven ?-) Thanks in advance for any input. Patrick Chanezon wrote: Hi all, I started working on struts-chain in order to add support for portlets. I built struts-chain from cvs, using a nightly struts 1.2 build jakarta-struts-20040113.zip to bootstrap my build, and my own build of commons-chain from CVS. I used the struts-example application from the nightly build as a seed for the struts-chains sample war. I deployed both in Tomcat 4.1.29. struts-example works fine struts-chain fails with an exception, see below. I have a few questions: 1. is someone actively working on that code right now ? 2. does someone have struts-chain installed and configured correctly ? from where did you get it ? Any caveats for the build ? 3. any idea about the Exception ? 4. I used maven to build struts: the maven dist target's result differs significantly from ant's dist, and contrib/struts-chain makes some assumptions about what's 2 levels above that are not met by the maven build. This is whay I had to use a nightly build. is there a way to generate jakarta-struts's build.properties from maven ?-) Thanks for any help. P@ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] ActionFactory refactoring
Vic Cekvenich wrote: Don Brown wrote: It would take probably a few hours to code so little effort is wasted when the struts-chain move takes place. I think that is the key at the end of the day. I think it be more effective the few hours be spent on integrating IoC into struts-chain Yes, integration of Struts-chain and IoC seems to hold a key for managing a group of services that are passed via Struts-Chain as a controller. I am exploring this with PicoContainer (using DefaultLifeCyclePicoContainer which provides both life cycle management and Config object). BaTien DBGROUPS but I do not need to remind anyone I am not a commiter, and even then each comiter can commit what they please, but I would rather see a design of IoC in CoR. If CoR already does digester, it can't be to far away from some level of alpha. I think it easier to work with a clean sheet of paper, but your preference, thanks for contributions. Maybe if there is a way to create a commons-IoC-api of interfaces that could be implemented as Nano, Hivemind, etc. and I duno. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Discussion Forum
Are we on something revolutionary here? I am looking forward to this.
BaTien
DBGROUPS
Don Brown wrote:
Is there one? I have several ideas I'd like to toss into the discussion.
Don
On 17 Dec 2003 [EMAIL PROTECTED] wrote:
husted 2003/12/17 12:49:28
Added: contrib/struts-jericho README.txt project.properties
project.xml
Log:
Create whiteboard directory for Struts-Jericho, a working proposal for Struts 2.x.
Revision ChangesPath
1.1 jakarta-struts/contrib/struts-jericho/README.txt
Index: README.txt
===
Jericho is a whiteboard proposal describing one possible implementation of Struts 2.x.
Since Struts 2.x is slated as a revolution, the Apache practice is to assign a codename to a proposal until the Community comes to a consensus.
This proposal is called Jericho since it tries to tear-down the walls within the Struts architecture. Jericho proposes to open-up Struts by
* Declaring interfaces for all core components.
* Providing working base implementations for all core components.
* Encapsulating alll path references within Location objects (fka ActionForwards)and referring only to Locations from all other objects.
* Providing additional extension points from core components so that the Inversion of Control pattern is fully realized.
* Providing POJO signatures that encapsulate HTTP classes so that applications can be freed of HTTP semantics, if so desired.
* Retain optional access to HTTP objects so that applications can be free to do whatever they need to do.
-Backward Compatibility-
Jericho is a revolution and backward compatability with prior versions of Struts is not the prime consideration. However, care is being taken to create a clear migration path, where practible, so that Jericho is available to the widest community possible.
_DTD._ The Jericho Configuration file (DTD) builds on the best aspects of the Struts 1.2 DTD. The elements are different but still similar. Our goal is to allow a tool, such as a XLST processor, to migrate a Struts 1.2 DTD to Struts Jericho.
A second alternative to explore is to provide an alternate configuration loader that would map the Struts 1.2 elements to Struts Jericho objects at initialization.
_Base Classes._ New base classes for Struts 1.2.x ActionForms and Actions are to provided. These classes will provide the Struts 1.2.x behavior but also implement the Struts Jericho interfaces, so that the framework can use them interchangeably.
These same techniques may be applied to provide adaptors for other frameworks, so as to make Struts Jericho available to the widest community possible.
###
1.1 jakarta-struts/contrib/struts-jericho/project.properties
Index: project.properties
===
# ---
# P R O J E C T P R O P E R T I E S
# ---
compile.debug = on
compile.optimize = off
compile.deprecation = off
maven.linkcheck.enable=true
# documentation properties
maven.xdoc.date=left
maven.xdoc.version=${pom.currentVersion}
maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/struts/status.html
1.1 jakarta-struts/contrib/struts-jericho/project.xml
Index: project.xml
===
?xml version=1.0 encoding=UTF-8?
project
extend../project.xml/extend
nameJericho/name
idstruts-jericho/id
currentVersion0.1-dev/currentVersion
inceptionYear2003/inceptionYear
shortDescriptionStruts Jericho 2.x Whiteboard/shortDescription
description
Jericho is a whiteboard proposal describing one possible implementation of
Struts 2.x.
Since Struts 2.x is slated as a revolution, the Apache practice is to assign
a codename to a proposal
until the Community comes to a consensus.
This proposal is called Jericho since it tries to tear-down the walls within
the Struts architecture.
/description
developers
developer
nameTed Husted/name
idhusted/id
email[EMAIL PROTECTED]/email
organization/organization
/developer
/developers
build
unitTest
includes
include**/*Test.java/include
/includes
/unitTest
/build
/project
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
.
Re: Portlets Framework
Howdy: Here is a framework we are working on with very promissing results: 1) User request is submitted to Struts request/response framework RequestProcessor (based on Struts-chain) 2) RequestProcessor passes information via ServletWebContext and looks into its Catalog of requested ServiceAction. 3) The ServiceAction uses all facilities of current Struts such as ServiceForm, Validation, etc. 4) The portal page has both static and dynamic fragments. The dynamic fragments are passed from ServletWebContext to PortletProcessor with contents stored in PortletWebContext. Note that ServletWebContext and PortletWebContext are just maps of name/value, same as cornerstone IContext. 5) PortletProcessor calls requested portlet(s) passed via contents in PortletWebContext. 6) Individual portlet calls its processActions and render which are 2 cornerstone services for component customization, component relationship, control flow customization, and component management. We are combining Cornerstone services and Hivemind services into our own services. This enable us to leverage on open-source low level developments and use it as a backdoor connection for different portlet applications which can be replaced with a more vendor neutral of JMS service. Security is a concern here, but if you wire various portlet applications together you are supposed to know what you are doing. The Struts pattern of service firewall such as ServiceForm can be used to avoid Trojan hourses. 7) Results of portlet renders recorded in PortletWebContext are returned the ServiceAction, which overwrite its contents in ServletWebContext with the contents in PortletWebContext. The results in ServletWebContext is passed to Struts-chain ResponseProcessor. 8) The ResponseProcessor passes ServletWebContext to the selected presentation engine, which can be any framework: JSP, JSF, Flex, XForm, WML, etc. The presentation engine renders the response using contents from ServletWebContext. Hope this may stimulate into the best flexible framework that we can all benefit. I thought this may be relevant to both Jetspeed and Struts, so I cross post in both. Sorry if it bothers you. BaTien DBGROUPS Weaver, Scott wrote: Hi Punit, For example if we want to apply some simple filter on request, which is the best place (if any) do to this? How to install common portlet filters? Remember, a JSR-168 compliant portal supports portlet applications as indivdual web apps deployed to the respective servlet container, this a requirement of the spec. Hence, you can use servlet filters within individual portlet apps to attain the filter functionallity required by each indivdual portlet application and the portlets contained within. It was crucial to the spec that it leverage as much functionallity from the servlet standard a possible so as to make portlet and servlet develop easy/similar as possible. Hth, ** | Scott T Weaver | | [EMAIL PROTECTED]| | Apache Jetspeed Portal Project | | Apache Pluto Portlet Container | ** -Original Message- From: Punit Pandey [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 17, 2003 8:03 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; portlets Subject: Portlets Framework Hello, We are in the process of developing one framework for portlets. The objective is to apply all possible patterns and also try to simplify the development process. The biggest challenge for developing portlet-framework, seems to us, is unavailability of controller servlet. In most of the JSP/Servlet-frameworks (e.g struts) the request always goes through the controller servlet. But in case of a portal, we do not have any such control. Can anyone tell me how to do some sort of request-preprocessing for a portlet? For example if we want to apply some simple filter on request, which is the best place (if any) do to this? How to install common portlet filters? Regards, Punit Pandey = http://portlets.blogspot.com - Portlets blog http://groups.yahoo.com/group/portle ts/ - Portlets Discussion Group - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] .
Re: [struts-chain] Some ideas
Craig R. McClanahan wrote: Quoting Konstantin Shaposhnikov [EMAIL PROTECTED]: Thank you for quick response and your ideas about the implementation. But can I ask you why I can't use the second approach with struts 1.1. I explore struts-chain code once again and found that I only need to change 1 Command in servlet-standard chain. You can certainly customize the chain if you want to use it with Struts 1.1, but that means you are playing with unreleased code and having to live with whatever restrictions exist (for instance, file upload is not currently supported in the existing chain definitions). I am imagining a day where we'd build the standard RequestProcessor for Struts 1.2 on top of the chain implementation. And what means provided for backwards compatibility with Struts 1.1 ? Will the next release replace Actions with something else? One of the key things people would look for from Struts 1.2 is a relatively easy migration of existing Struts-based apps. Therefore, it would seem best for us to be able to call an app's existing Action classes (as the current struts-chain implementation does). In a future world solely based on chain, you wouldn't need the idea of an Action class at all. Instead, you'd map the action element in struts-config.xml to the name of a chain, which could either be a single Command or a series of Commands -- Struts would not care. In this environment, there would still be a standard set of commands in the standard chain, to do all the standard stuff (like populating a form bean, performing validation, and so on). But the thinking is that the app's business logic would be built out of chains as well, which can (of course) be arbitrarily complex in their internal structure. Among other things, this would allow people to not have to attempt to use action chaining, which today causes surprising results. Instead, you could build little two-Command chains -- the first would process the form submit, and the second would do the appropriate setup for the next page to be displayed. Because these two behaviors would be separated, you could reuse either or both of them (for example, cases you need to forward to a particular page from more than one place, and perform the same setup behavior each time, could share the second command. In fact, that is what we are attempting to do. For any atomic process, i think there are 3 repeatable components: data collection, rule analysis based on collected data, and desion based on the analysis. I am planning to build these re-useable components based on the chain filter. I hope this will stimulate the interest in the chain of commands. I am also looking forward to the chain of commands applied to portlet, especially: 1) the modeling of 2 chains: 1 for portlet action and 1 for portlet render using the same context 2) the passing of data fron Struts ServletWebContext to PortletWebContext to PortletRequest and PortletResponse that will be used on top of Pluto portlet container. 3) the passing from portlet action to the business processor chain so a different business chain is used in the business layer. Many promissing uses can be happened. BaTien DBGROUPS best regards, Konstantin Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] .
Re:Struts-chain
Howdy:
I am trying to get Struts-chain up and running. I follow the instruction
of struts-chain in the cvs to build from the source:
export ANT_HOME=.../ant-1.6beta2
export JAVA_HOME=.../j2sdk1.4.2_02
export TOMCAT_HOME=.../tomcat-5.0.14
The build.properties is copied from the build.properties.sample
servlet.home=.../common/lib
struts.home=.../jakarta-struts-bin
chain.home=.../cvs/jakarta-commons-sandbox/chain
export
PATH=${PATH}:${JAVA_HOME}/bin:${ANT_HOME}/bin:${TOMCAT_HOME}/common/lib/servlet-api.jar:${TOMCAT_HOME}/server/lib/catalina-ant.jar
execute the following command at the struts-chain directory
[-]$ ant clean dist
I got the error:
/build.xml:54: taskdef class org.apache.catalina.ant.DeployTask could
not be found
Please feed me the latest instruction to create struts-chain.war
Thanks
BaTien
DBGROUPS
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where is Struts 2 going?
Craig R. McClanahan wrote: On Tue, 16 Sep 2003, Mete Kural wrote: Date: Tue, 16 Sep 2003 11:14:03 +0100 From: Mete Kural [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Where is Struts 2 going? Great! I read the whiteboard. Do you know when the development for the portlet related aspects of Struts 2.0 may begin. I know that there are some Jetspeed developers who are interested in contributing to a project that aims to turn Struts into a portlet framework. I think that adding more committers to Struts that are coming from a portal/portlet background would be of great benefit to the development of Struts 2.0. Unfortunately, I am under-skilled for that, but I can refer some individuals to you who have the skills from the Jetspeed project, if you wish. One approach to dealing with it has (in fact) already begun -- in the contrib/struts-chain subdirectory in the CVS sources is the beginnings of a refactoring of the standard RequestProcessor based on the commons-chain package in the Commons Sandbox. If this actually works, two really good things might be able to happen: * It'll work for both servlets and portlets (you can see how the command implementations are being abstracted so that the chain will just do the right thing for each environment). * It is likely to be backwards compatible with Struts 1.1 as well, possibly with some restrictions yet to be discovered. The best way to get involved would be to check out CVS sources for both jakarta-struts and jakarta-commons-sandbox, become familiar with the code referenced above, and start making suggestions and improvements. A really good starting point would be portlet-specific implementations of all the commands that currently have only servlet-specific implementations. Regards, Mete Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This is a very exiting area. I am committed in both Struts-2 and Jetspeed-2. BaTien DBGROUPS
Re: JSR 168 and Struts
Clay Richardson wrote: I apologize if anyone has already asked this question, but I searched the board and didn't see it. Also, I tried the user forum first, but figured maybe this was more appropriate. JSR 168 has the following line in it (Section PLT.16.3): Servlets and JSPs included from portlets should not use the servlet RequestDispatcher forward method as its behavior may be non-deterministic. Yes, this is one of my concern as well and did not response to this question in user group since i have not put enough time in it. It seems to me that Struts needs to be refactoring to be MVC for portlets since portlets can delegate the creation of content to servlet and JSP via PortletRequestDispatcher. If there is a proper hook then Tiles can still be an intelligent assembling part of the view. Craig is the best guy to iron these issues. BaTien DBGROUPS I am no expert on Struts, although I have used it quite a bit. It seems that if I wanted to wrap my Struts app in a Portlet and access various actions through the PortletRequestDispatcher (the most logical approach), I would run afoul of this warning. Lacking an implementation to test my hypothesis (*$# IBM legal department), I am unsure whether this actually fails or not. My gut instinct is that it probably wouldn't, but that it may not be reliable across implementations of servlet and portlet containers. I wanted to get some thoughts from the Struts community about this possible issue. Also, I wanted to know what the impact would be of using RequestDispatcher's include method instead? Or at least providing the facility to portlet developers? I apologize if I have wrongly assumed anything in my question. This is my best estimate based on what I have read. Thanks, Clay Richardson W. Clay Richardson Adjunct Professor of Computer Science Northern Virginia Graduate Center Virginia Polytechnic Institute and State University Oh, and how is education supposed to make me feel smarter? Besides, every time I learn something new, it pushes some old stuff out of my brain. Remember when I took that home wine-making course and I forgot how to drive? - Homer J. Simpson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts for Portlets (requesting your opinions)
Mete Kural wrote: Agree. I just read Craig ideal view and I think this view may be a good start. I think so too. I will re-state Craig's ideal goal below for others to catch up: I believe that we should aim for the following ideal state -- a Struts application shoud be usable either as a webapp or as a portlet, with little (ideally no) changes. Therefore, I believe that we'd build whatever it takes to support this into the standard Struts distribution, which would then be used in both environments. I would like to ask everybody what their opinions are about this topic. Is it technically possible for Struts to enable the same application to be turned into a webapp or a portlet at the switch of a button? Could the fundamental differences between a webapp and a portlet not allow such a possibility? Mete I think somewhere in Bea dev2dev, there is a download to make Struts app as a JSR-168 portlet running in Bea portal container. I am more interesting in using Struts with no burden and complexity of proprietary technologies. Sticking to formal standards, it is easy to adapt to any required proprietary environment. BaTien DBGROUPS -- Original Message -- From: BaTien Duong [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] Date: Wed, 13 Aug 2003 12:24:47 -0600 Agree. I just read Craig ideal view and I think this view may be a good start. BaTien DBGROUPS Mete Kural wrote: Struts-Tiles-Portal-Portlet framework and container. I think that there is a big difference between the framework used to build a portal server and a portlet framework. I see that Struts+Tiles is a very good framework to build a portal server, but it seems to me that the ways in which Struts would be used as a framework for building a portal server are very different than Struts being used as a portlet framework. IMHO, Struts developers should focus on making Struts an efficient portlet framework. Portal server developers could tweak Struts in their own ways in order to use it as a framework for building their portal server, but I don't see the need for standardization in this area. Standardization is rather necessary in the are of using Struts as a portlet framework. What are your opinions? -Mete -- Original Message -- From: BaTien Duong [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] Date: Wed, 13 Aug 2003 11:02:44 -0600 Greetings: I am very interested in this discussion, and will have more time to think of the overall structure after the release of JSR-168 Reference Implementation (Pluto). At a cursory level, i see Struts provides very simple and elegant flow controllers of what-to-do and how-to-do based on standard Servlet container. Tiles is an elegant dynamic templating engine, also based on standard Servlet container. I see JSP tiles as a plus rather than a short-coming since J2EE has JSP as its dynamic page assembling. JSR-168 portal/portlet containers are official extension of Servlet container. It seems not a very major issue to make Struts and tiles a 1-2 punch for JSR-168 portal/portlet containers. Tiles context may be refactored into Portlet context. Tiles already has a facility to dynamically generate tile attributes for changing the page assembling. This is probably what the JSR-168 authors mention that Portlet can act as controller, fill a bean with data, and include a JSP to render the output. See this pattern? The effort is valuable, since many Struts Plug-ins can be parts of our tools. I see Jetspeed is too heavy, not simple and elegant enough to realize the potential of JSR-168 and WSRP. We can learn many designs from Jetspeed to bring them into this new portal/portlet framework with simple and elegant design infrastructure. I hope many designers and developers interested in this relevant topic: Struts-Tiles-Portal-Portlet framework and container. BaTien DBGROUPS Mete Kural wrote: Hello Struts developers, I wanted to get your opinions on how Struts should be used as a portlet framework. I think that it would be great if a portlet framework was part of the standard Struts distribution in the near future. JSR-168 which defines standard portlets will be finalized pretty soon (a month?), although the specification draft is pretty much stable hereafter. I have two main questions: 1) My first question is technical. How do you think portlet support would be best added to Struts? Which classes should be extended? Are there necessary changes at the core classes of Struts in order to provide an efficient framework for building portlets? 2) Second question is about how a Struts-based or Struts-like portlet framework should be distributed. Should it be part of the core Struts distribution? Should there be two different Struts distributions within the Struts project: Struts for Webapps and Struts
Re: Struts for Portlets
Agree. I just read Craig ideal view and I think this view may be a good start. BaTien DBGROUPS Mete Kural wrote: Struts-Tiles-Portal-Portlet framework and container. I think that there is a big difference between the framework used to build a portal server and a portlet framework. I see that Struts+Tiles is a very good framework to build a portal server, but it seems to me that the ways in which Struts would be used as a framework for building a portal server are very different than Struts being used as a portlet framework. IMHO, Struts developers should focus on making Struts an efficient portlet framework. Portal server developers could tweak Struts in their own ways in order to use it as a framework for building their portal server, but I don't see the need for standardization in this area. Standardization is rather necessary in the are of using Struts as a portlet framework. What are your opinions? -Mete -- Original Message -- From: BaTien Duong [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] Date: Wed, 13 Aug 2003 11:02:44 -0600 Greetings: I am very interested in this discussion, and will have more time to think of the overall structure after the release of JSR-168 Reference Implementation (Pluto). At a cursory level, i see Struts provides very simple and elegant flow controllers of what-to-do and how-to-do based on standard Servlet container. Tiles is an elegant dynamic templating engine, also based on standard Servlet container. I see JSP tiles as a plus rather than a short-coming since J2EE has JSP as its dynamic page assembling. JSR-168 portal/portlet containers are official extension of Servlet container. It seems not a very major issue to make Struts and tiles a 1-2 punch for JSR-168 portal/portlet containers. Tiles context may be refactored into Portlet context. Tiles already has a facility to dynamically generate tile attributes for changing the page assembling. This is probably what the JSR-168 authors mention that Portlet can act as controller, fill a bean with data, and include a JSP to render the output. See this pattern? The effort is valuable, since many Struts Plug-ins can be parts of our tools. I see Jetspeed is too heavy, not simple and elegant enough to realize the potential of JSR-168 and WSRP. We can learn many designs from Jetspeed to bring them into this new portal/portlet framework with simple and elegant design infrastructure. I hope many designers and developers interested in this relevant topic: Struts-Tiles-Portal-Portlet framework and container. BaTien DBGROUPS Mete Kural wrote: Hello Struts developers, I wanted to get your opinions on how Struts should be used as a portlet framework. I think that it would be great if a portlet framework was part of the standard Struts distribution in the near future. JSR-168 which defines standard portlets will be finalized pretty soon (a month?), although the specification draft is pretty much stable hereafter. I have two main questions: 1) My first question is technical. How do you think portlet support would be best added to Struts? Which classes should be extended? Are there necessary changes at the core classes of Struts in order to provide an efficient framework for building portlets? 2) Second question is about how a Struts-based or Struts-like portlet framework should be distributed. Should it be part of the core Struts distribution? Should there be two different Struts distributions within the Struts project: Struts for Webapps and Struts for Portlets? Or should it be a seperate Jakarta project? I look forward to hearing your opinions. Thank you very much. Mete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts for Portlets
Greetings: I am very interested in this discussion, and will have more time to think of the overall structure after the release of JSR-168 Reference Implementation (Pluto). At a cursory level, i see Struts provides very simple and elegant flow controllers of what-to-do and how-to-do based on standard Servlet container. Tiles is an elegant dynamic templating engine, also based on standard Servlet container. I see JSP tiles as a plus rather than a short-coming since J2EE has JSP as its dynamic page assembling. JSR-168 portal/portlet containers are official extension of Servlet container. It seems not a very major issue to make Struts and tiles a 1-2 punch for JSR-168 portal/portlet containers. Tiles context may be refactored into Portlet context. Tiles already has a facility to dynamically generate tile attributes for changing the page assembling. This is probably what the JSR-168 authors mention that Portlet can act as controller, fill a bean with data, and include a JSP to render the output. See this pattern? The effort is valuable, since many Struts Plug-ins can be parts of our tools. I see Jetspeed is too heavy, not simple and elegant enough to realize the potential of JSR-168 and WSRP. We can learn many designs from Jetspeed to bring them into this new portal/portlet framework with simple and elegant design infrastructure. I hope many designers and developers interested in this relevant topic: Struts-Tiles-Portal-Portlet framework and container. BaTien DBGROUPS Mete Kural wrote: Hello Struts developers, I wanted to get your opinions on how Struts should be used as a portlet framework. I think that it would be great if a portlet framework was part of the standard Struts distribution in the near future. JSR-168 which defines standard portlets will be finalized pretty soon (a month?), although the specification draft is pretty much stable hereafter. I have two main questions: 1) My first question is technical. How do you think portlet support would be best added to Struts? Which classes should be extended? Are there necessary changes at the core classes of Struts in order to provide an efficient framework for building portlets? 2) Second question is about how a Struts-based or Struts-like portlet framework should be distributed. Should it be part of the core Struts distribution? Should there be two different Struts distributions within the Struts project: Struts for Webapps and Struts for Portlets? Or should it be a seperate Jakarta project? I look forward to hearing your opinions. Thank you very much. Mete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Security Solution
Please post and/or send 1 copy to me. Thanks. - Original Message - From: Phase Web and Multimedia [EMAIL PROTECTED] To: Struts User [EMAIL PROTECTED]; Struts Developers List [EMAIL PROTECTED] Sent: Monday, April 01, 2002 11:49 AM Subject: Security Solution Greetings, I wanted to offer some code if anyone is interested. I have seen many discuss security on archives and wanted to offer an alternative to container managed security. I spent some time weighing out whether to use container managed security or not and came to the conclusion that I would use a filter for security. There were several inflexibilities in the spec for container managed security. I wrote a security filter that functions very similar to container managed security. It has an xml config file that is used to protect urls. There are a few differences in the config and how you define protected areas and where you are directed. Basically there are three areas of greater flexibility. 1) you can define several security-constraint groups with different login pages. 2) you can login easily without having to hit a secure page first 3) you can set up an app specific security realm. (This can also be considered a limitation if you are maintaining cross context security, but you could easily tie into a larger security system if this is needed) Anyways, it is not the standard but it functions well and gives greater freedom. I found container managed security to be a greater hack job when I wanted to accomplish my goals. If anybody is interested I can post it for review. It is certainly not mature and the code is fit for my current situation with an eye to greater flexibility. I think that it could provide a good starting point for a cross-container simple alternate solution to the current container managed security. P.S. I have to improve the documentation :-) Thanks for your time, Brandon Goodin Phase Web and Multimedia P (406) 862-2245 F (406) 862-0354 [EMAIL PROTECTED] http://www.phase.ws -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Single Signon (was role based actions)
Yes, I am interested in exploring open souce solution for single SignOn. I am watching Liberty Alliance, while internally develop solution based on JAAS, OpenLDAP, and Kerberos. BaTien - Original Message - From: Sandra Cann [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Monday, December 31, 2001 10:09 AM Subject: Single Signon (was role based actions) Batien et al, I wonder if members of this list would be interested in collaborating with the Expresso community on single sign-on features via our opensource listserv or the Expresso Users Forum (Single Sign-on topic). The following document url is a summation of a detailed discussion on single sign on from our open source listserv which you might find interesting since Expresso utilizes Struts. (There is also a link to the open source archives on the home page.) http://www.jcorporate.com/econtent/Content.do?state=resourceresource=615 (you will need to be registered at www.jcorporate.com and login to view). cheers Sandra -Original Message- From: Dr. BaTien Duong [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 11, 2001 7:53 PM To: Struts Developers List Subject: Re: role based actions Brandon: I am interested in your code as we are working on Struts, ldap, and Java single SignOn technology. [EMAIL PROTECTED] - Original Message - From: Phase Communcations [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, December 11, 2001 4:43 PM Subject: RE: role based actions One last thing. When a security check happens and the user is forwarded to the login. Their desired destination is stored and once their security is verified they are forwarded on to that page. -Original Message- From: Phase Communcations [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 11, 2001 4:40 PM To: Struts Developers List Subject: RE: role based actions In my code I extended the action class (not the action servlet) and required that group access be established on a per extended action class basis. Defined within my struts-config file in my action class definitions I use an extra attribute(s): set-property property=group value=agroup / There is a security check within the extended action class that uses an extended ActionMapping to retrieve the group property and checks it against the users information (in a database). If the user belongs to the proper group or one of the groups defined then it allows them access to that action/area with their assigned role and permissions. If the security check fails, they are routed to a login page. The other thing that it does is it stores role and permission information in a bean so that security information can be used to define the view as well. I opted out of the container managed security because I was working under Tomcat 3.2.3 and am trying to create a more independent security model. This model also works well for me because I use the command line url format for mapping to my action classes and none of my views are available but through action classes (except index.jsp). I would be happy to share my code if anyone is interested. I think it is flexible enough that it could be incorporated into an ldap system. I have been confeing with a colleague who is working on struts interacting with ldap for security and profile management. Anyways if you like the idea of security being managed from the action class and don't expose your views but through action mappings. This might be a good solution Brandon Goodin Phase Web and Multimedia P (406) 862-2245 F (406) 862-0354 [EMAIL PROTECTED] http://www.phase.ws -Original Message- From: craigmcc@localhost [mailto:craigmcc@localhost]On Behalf Of Craig R. McClanahan Sent: Tuesday, December 11, 2001 10:16 AM To: Struts Developers List Subject: Re: role based actions On Tue, 11 Dec 2001 [EMAIL PROTECTED] wrote: Date: Tue, 11 Dec 2001 10:27:52 -0500 From: [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: role based actions I am a struts newbie so I apologize in advance if this topic has already beaten to death... ~~~ I noticed role-based actions on the pending tasks list. Adding this (and a few of the other recent enhancements) to Struts 1.1 is definitely on *my* list. I will have some time to do so between Christmas and New Years. Craig McClanahan Can anyone comment on the status and scope of this effort? (link was a dead end) The description points to role being driven by security, seems the role will be detected and then dispatches to the proper action? points
Re: role based actions
Brandon: I am interested in your code as we are working on Struts, ldap, and Java single SignOn technology. [EMAIL PROTECTED] - Original Message - From: Phase Communcations [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, December 11, 2001 4:43 PM Subject: RE: role based actions One last thing. When a security check happens and the user is forwarded to the login. Their desired destination is stored and once their security is verified they are forwarded on to that page. -Original Message- From: Phase Communcations [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 11, 2001 4:40 PM To: Struts Developers List Subject: RE: role based actions In my code I extended the action class (not the action servlet) and required that group access be established on a per extended action class basis. Defined within my struts-config file in my action class definitions I use an extra attribute(s): set-property property=group value=agroup / There is a security check within the extended action class that uses an extended ActionMapping to retrieve the group property and checks it against the users information (in a database). If the user belongs to the proper group or one of the groups defined then it allows them access to that action/area with their assigned role and permissions. If the security check fails, they are routed to a login page. The other thing that it does is it stores role and permission information in a bean so that security information can be used to define the view as well. I opted out of the container managed security because I was working under Tomcat 3.2.3 and am trying to create a more independent security model. This model also works well for me because I use the command line url format for mapping to my action classes and none of my views are available but through action classes (except index.jsp). I would be happy to share my code if anyone is interested. I think it is flexible enough that it could be incorporated into an ldap system. I have been confeing with a colleague who is working on struts interacting with ldap for security and profile management. Anyways if you like the idea of security being managed from the action class and don't expose your views but through action mappings. This might be a good solution Brandon Goodin Phase Web and Multimedia P (406) 862-2245 F (406) 862-0354 [EMAIL PROTECTED] http://www.phase.ws -Original Message- From: craigmcc@localhost [mailto:craigmcc@localhost]On Behalf Of Craig R. McClanahan Sent: Tuesday, December 11, 2001 10:16 AM To: Struts Developers List Subject: Re: role based actions On Tue, 11 Dec 2001 [EMAIL PROTECTED] wrote: Date: Tue, 11 Dec 2001 10:27:52 -0500 From: [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: role based actions I am a struts newbie so I apologize in advance if this topic has already beaten to death... ~~~ I noticed role-based actions on the pending tasks list. Adding this (and a few of the other recent enhancements) to Struts 1.1 is definitely on *my* list. I will have some time to do so between Christmas and New Years. Craig McClanahan Can anyone comment on the status and scope of this effort? (link was a dead end) The description points to role being driven by security, seems the role will be detected and then dispatches to the proper action? points to assoc'd form through config? Is this intended to be used for personalization to the extent where a person of one role gets a different view, can user customize their view? Does this provide a place holder for that kind of functionality v. any particular built in functionality? Thanks, sorry if the questions were a little obtuse. -Rick Vaillancourt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
