Re: How to use CSVDataExporter
We have IExportableColumn
where T is the type of each row in the table.
where S is the type of the sort property of the table.
and the method
public void exportData(IDataProvider dataProvider,
List> columns, OutputStream outputStream)
try
List> columns = new
ArrayList>();
François Meillet
Formation Wicket - Développement Wicket
Le 5 nov. 2014 à 15:47, suvojit168 a écrit :
> Hi,
>
> I am trying to export data to csv in my wicket pages. I am using
> CSVDataExporter for this purpose. Due to some constraints I am not using it
> in conjunction to ExportToolbar. There is a link and on click of the link I
> am trying to call exportData() on instance of CSVDataExporter.
> I am using AbstractExportableColumn for columns writing data to columns.
>
> However I am getting a compile time error on exportData. Follwoing is the
> code (excelDataImport is the link here ):
>
> excelDataImport.add(new AjaxEventBehavior("onclick") {
> private static final long serialVersionUID = 1L;
>
> protected void onEvent(AjaxRequestTarget target) {
> List String, String>> columns = new
> ArrayList>();
> columns.add(new
> AbstractExportableColumn String>(new Model("Affiliate Name"), "name") {
>
> @Override
> public IModel getDataModel(
> IModel
> arg0) {
> // TODO Auto-generated method
> stub
> return null;
> }
>
> });
>
> try {
> new CSVDataExporter().exportData(new
> AffiliateDataProvider(null),
> columns, new FileOutputStream("test.xls"));
> } catch (FileNotFoundException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (IOException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (Exception e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
>
>
>
>
> }
> });
>
> The error message is : "The method exportData(IDataProvider,
> List>, OutputStream) in the type CSVDataExporter
> is not applicable for the arguments (AffiliateDataProvider,
> List>,
> FileOutputStream)".
>
> I think I did it all correctly (as per whatever knowledge I could get on
> this subject), am I doing something wrong here?
>
> Also, can anyone share with me some sample examples and description/details
> for CSVDataExporter? I have gone through example in DataTablePage.java in
> wicket example but that is using DataTable and ExportToolbar.
>
> Thanks,
> Suvojit
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/How-to-use-CSVDataExporter-tp4668270.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
How to use CSVDataExporter
Hi,
I am trying to export data to csv in my wicket pages. I am using
CSVDataExporter for this purpose. Due to some constraints I am not using it
in conjunction to ExportToolbar. There is a link and on click of the link I
am trying to call exportData() on instance of CSVDataExporter.
I am using AbstractExportableColumn for columns writing data to columns.
However I am getting a compile time error on exportData. Follwoing is the
code (excelDataImport is the link here ):
excelDataImport.add(new AjaxEventBehavior("onclick") {
private static final long serialVersionUID = 1L;
protected void onEvent(AjaxRequestTarget target) {
List> columns = new
ArrayList>();
columns.add(new
AbstractExportableColumn(new Model("Affiliate Name"), "name") {
@Override
public IModel getDataModel(
IModel
arg0) {
// TODO Auto-generated method
stub
return null;
}
});
try {
new CSVDataExporter().exportData(new
AffiliateDataProvider(null),
columns, new FileOutputStream("test.xls"));
} catch (FileNotFoundException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
});
The error message is : "The method exportData(IDataProvider,
List>, OutputStream) in the type CSVDataExporter
is not applicable for the arguments (AffiliateDataProvider,
List>,
FileOutputStream)".
I think I did it all correctly (as per whatever knowledge I could get on
this subject), am I doing something wrong here?
Also, can anyone share with me some sample examples and description/details
for CSVDataExporter? I have gone through example in DataTablePage.java in
wicket example but that is using DataTable and ExportToolbar.
Thanks,
Suvojit
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/How-to-use-CSVDataExporter-tp4668270.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 6 Session issue
Thanks ! It is more clear now ! On Wed, Nov 5, 2014 at 3:44 PM, Wayne W wrote: > Sorry Martin its not clear enough. This any better? > > >1. Tomcat1 / Session A / Thread 1: User goes to : my.example.com/login > (LoginPage.java) >2. Tomcat1 / Session A / Thread 2: They log in >3. Tomcat 1 / Session A / Thread 2 : We invalidate the session and do a >redirect to : foo.example.com/login passing some parameters >4. Tomcat 2 / Session B / Thread 1: In the constructor of LoginPage we >verify the parameters and if valid setup up the new current session with >the user's details (Session.setUser(user)) >5. Tomcat 2/ Session B / Thread 1: LoginPage then does >a setResponsePage(Application.get().getHomePage()); > try by adding getSession().bind(); at step 5 >6. Tomcat 2/Session B / Thread >1: MetaDataRoleAuthorizationStrategy.isInstantiationAuthorized() finds >null in the Session (Session.getUser() ) > > > > > On Wed, Nov 5, 2014 at 11:22 AM, Martin Grigorov > wrote: > > > Then your first mail misleads. > > Would you please explain again the steps with more details which step on > > which node happens. > > > > Martin Grigorov > > Wicket Training and Consulting > > https://twitter.com/mtgrigorov > > > > On Wed, Nov 5, 2014 at 1:01 PM, Wayne W > > wrote: > > > > > Hi Martin, > > > > > > I don't think this is anything to do with session replication, as we > > > invalidate the session at step 3 and its not about trying to pick the > > > session up on a different instance. Its about creating a new session > > from a > > > redirect where the issue seems. We do use sticky session load balancing > > via > > > the JSESSION cookie on apache. > > > > > > > > > > > > On Wed, Nov 5, 2014 at 10:56 AM, Martin Grigorov > > > > wrote: > > > > > > > Hi, > > > > > > > > As far as I know the session replication supporting code is the same > > > since > > > > Wicket 1.4.1 (or 1.4.2). > > > > > > > > The Wicket Session object is saved as an attribute in the > HttpSession. > > > The > > > > HttpSession is replicated by Tomcat itself. What is your Tomcat > config > > > > related to replication ? > > > > Do you use sticky sessions ? It seems you don't but I have to ask. > > > > > > > > Martin Grigorov > > > > Wicket Training and Consulting > > > > https://twitter.com/mtgrigorov > > > > > > > > On Wed, Nov 5, 2014 at 12:43 PM, Wayne W < > waynemailingli...@gmail.com> > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > we recently migrated to 6.17 from 4.x. Something we are now > > > experiencing > > > > is > > > > > an odd session problem in production. > > > > > > > > > > We have 2 tomcats load balance running the front end wicket code. > We > > > > have a > > > > > certain flow that goes like this: > > > > > > > > > > > > > > >1. User goes to : my.example.com/login (LoginPage.java) > > > > >2. They log in > > > > >3. We invalidate the session and do a redirect to : > > > > > foo.example.com/login > > > > >passing some parameters > > > > >4. In the constructor of LoginPage we verify the parameters and > if > > > > valid > > > > >setup up the new current session with the user's details > > > > >5. LoginPage then does > > > > >a setResponsePage(Application.get().getHomePage()); > > > > > > > > > > This on a single node/machine/instance of tomcat works great and > with > > > > > Wicket 4 it also worked great in a 2 node/instance load balanced > > > > situation > > > > > however we have a problem. > > > > > > > > > > Problem: > > > > > If at step 3 the redirect gets load balances to a different > instance > > of > > > > > tomcat, step 4 works fine (the request is read the the new session > is > > > got > > > > > and the user info set on it). But this is when it gets really odd. > > > Step 5 > > > > > is executed fine, but when the home page is constructed > > > > > our MetaDataRoleAuthorizationStrategy.isInstantiationAuthorized() > is > > > > > called as normal, and when we check the session to see if the users > > > > details > > > > > are ok, there is no user in the session at all and we have a > > different > > > > > session ! > > > > > > > > > > Any ideas at all what is happening here? Did something change > around > > > the > > > > > session handling? I'm wondering if its something to do with the 302 > > > > > redirect to the new URL with parameters? > > > > > > > > > > many thanks > > > > > > > > > > > > > > >
Re: Wicket 6 Session issue
Sorry Martin its not clear enough. This any better? 1. Tomcat1 / Session A / Thread 1: User goes to : my.example.com/login (LoginPage.java) 2. Tomcat1 / Session A / Thread 2: They log in 3. Tomcat 1 / Session A / Thread 2 : We invalidate the session and do a redirect to : foo.example.com/login passing some parameters 4. Tomcat 2 / Session B / Thread 1: In the constructor of LoginPage we verify the parameters and if valid setup up the new current session with the user's details (Session.setUser(user)) 5. Tomcat 2/ Session B / Thread 1: LoginPage then does a setResponsePage(Application.get().getHomePage()); 6. Tomcat 2/Session B / Thread 1: MetaDataRoleAuthorizationStrategy.isInstantiationAuthorized() finds null in the Session (Session.getUser() ) On Wed, Nov 5, 2014 at 11:22 AM, Martin Grigorov wrote: > Then your first mail misleads. > Would you please explain again the steps with more details which step on > which node happens. > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Wed, Nov 5, 2014 at 1:01 PM, Wayne W > wrote: > > > Hi Martin, > > > > I don't think this is anything to do with session replication, as we > > invalidate the session at step 3 and its not about trying to pick the > > session up on a different instance. Its about creating a new session > from a > > redirect where the issue seems. We do use sticky session load balancing > via > > the JSESSION cookie on apache. > > > > > > > > On Wed, Nov 5, 2014 at 10:56 AM, Martin Grigorov > > wrote: > > > > > Hi, > > > > > > As far as I know the session replication supporting code is the same > > since > > > Wicket 1.4.1 (or 1.4.2). > > > > > > The Wicket Session object is saved as an attribute in the HttpSession. > > The > > > HttpSession is replicated by Tomcat itself. What is your Tomcat config > > > related to replication ? > > > Do you use sticky sessions ? It seems you don't but I have to ask. > > > > > > Martin Grigorov > > > Wicket Training and Consulting > > > https://twitter.com/mtgrigorov > > > > > > On Wed, Nov 5, 2014 at 12:43 PM, Wayne W > > > wrote: > > > > > > > Hi, > > > > > > > > we recently migrated to 6.17 from 4.x. Something we are now > > experiencing > > > is > > > > an odd session problem in production. > > > > > > > > We have 2 tomcats load balance running the front end wicket code. We > > > have a > > > > certain flow that goes like this: > > > > > > > > > > > >1. User goes to : my.example.com/login (LoginPage.java) > > > >2. They log in > > > >3. We invalidate the session and do a redirect to : > > > > foo.example.com/login > > > >passing some parameters > > > >4. In the constructor of LoginPage we verify the parameters and if > > > valid > > > >setup up the new current session with the user's details > > > >5. LoginPage then does > > > >a setResponsePage(Application.get().getHomePage()); > > > > > > > > This on a single node/machine/instance of tomcat works great and with > > > > Wicket 4 it also worked great in a 2 node/instance load balanced > > > situation > > > > however we have a problem. > > > > > > > > Problem: > > > > If at step 3 the redirect gets load balances to a different instance > of > > > > tomcat, step 4 works fine (the request is read the the new session is > > got > > > > and the user info set on it). But this is when it gets really odd. > > Step 5 > > > > is executed fine, but when the home page is constructed > > > > our MetaDataRoleAuthorizationStrategy.isInstantiationAuthorized() is > > > > called as normal, and when we check the session to see if the users > > > details > > > > are ok, there is no user in the session at all and we have a > different > > > > session ! > > > > > > > > Any ideas at all what is happening here? Did something change around > > the > > > > session handling? I'm wondering if its something to do with the 302 > > > > redirect to the new URL with parameters? > > > > > > > > many thanks > > > > > > > > > >
Re: Wicket 6 Session issue
Then your first mail misleads. Would you please explain again the steps with more details which step on which node happens. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Wed, Nov 5, 2014 at 1:01 PM, Wayne W wrote: > Hi Martin, > > I don't think this is anything to do with session replication, as we > invalidate the session at step 3 and its not about trying to pick the > session up on a different instance. Its about creating a new session from a > redirect where the issue seems. We do use sticky session load balancing via > the JSESSION cookie on apache. > > > > On Wed, Nov 5, 2014 at 10:56 AM, Martin Grigorov > wrote: > > > Hi, > > > > As far as I know the session replication supporting code is the same > since > > Wicket 1.4.1 (or 1.4.2). > > > > The Wicket Session object is saved as an attribute in the HttpSession. > The > > HttpSession is replicated by Tomcat itself. What is your Tomcat config > > related to replication ? > > Do you use sticky sessions ? It seems you don't but I have to ask. > > > > Martin Grigorov > > Wicket Training and Consulting > > https://twitter.com/mtgrigorov > > > > On Wed, Nov 5, 2014 at 12:43 PM, Wayne W > > wrote: > > > > > Hi, > > > > > > we recently migrated to 6.17 from 4.x. Something we are now > experiencing > > is > > > an odd session problem in production. > > > > > > We have 2 tomcats load balance running the front end wicket code. We > > have a > > > certain flow that goes like this: > > > > > > > > >1. User goes to : my.example.com/login (LoginPage.java) > > >2. They log in > > >3. We invalidate the session and do a redirect to : > > > foo.example.com/login > > >passing some parameters > > >4. In the constructor of LoginPage we verify the parameters and if > > valid > > >setup up the new current session with the user's details > > >5. LoginPage then does > > >a setResponsePage(Application.get().getHomePage()); > > > > > > This on a single node/machine/instance of tomcat works great and with > > > Wicket 4 it also worked great in a 2 node/instance load balanced > > situation > > > however we have a problem. > > > > > > Problem: > > > If at step 3 the redirect gets load balances to a different instance of > > > tomcat, step 4 works fine (the request is read the the new session is > got > > > and the user info set on it). But this is when it gets really odd. > Step 5 > > > is executed fine, but when the home page is constructed > > > our MetaDataRoleAuthorizationStrategy.isInstantiationAuthorized() is > > > called as normal, and when we check the session to see if the users > > details > > > are ok, there is no user in the session at all and we have a different > > > session ! > > > > > > Any ideas at all what is happening here? Did something change around > the > > > session handling? I'm wondering if its something to do with the 302 > > > redirect to the new URL with parameters? > > > > > > many thanks > > > > > >
Re: Wicket 6 Session issue
Hi Martin, I don't think this is anything to do with session replication, as we invalidate the session at step 3 and its not about trying to pick the session up on a different instance. Its about creating a new session from a redirect where the issue seems. We do use sticky session load balancing via the JSESSION cookie on apache. On Wed, Nov 5, 2014 at 10:56 AM, Martin Grigorov wrote: > Hi, > > As far as I know the session replication supporting code is the same since > Wicket 1.4.1 (or 1.4.2). > > The Wicket Session object is saved as an attribute in the HttpSession. The > HttpSession is replicated by Tomcat itself. What is your Tomcat config > related to replication ? > Do you use sticky sessions ? It seems you don't but I have to ask. > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Wed, Nov 5, 2014 at 12:43 PM, Wayne W > wrote: > > > Hi, > > > > we recently migrated to 6.17 from 4.x. Something we are now experiencing > is > > an odd session problem in production. > > > > We have 2 tomcats load balance running the front end wicket code. We > have a > > certain flow that goes like this: > > > > > >1. User goes to : my.example.com/login (LoginPage.java) > >2. They log in > >3. We invalidate the session and do a redirect to : > > foo.example.com/login > >passing some parameters > >4. In the constructor of LoginPage we verify the parameters and if > valid > >setup up the new current session with the user's details > >5. LoginPage then does > >a setResponsePage(Application.get().getHomePage()); > > > > This on a single node/machine/instance of tomcat works great and with > > Wicket 4 it also worked great in a 2 node/instance load balanced > situation > > however we have a problem. > > > > Problem: > > If at step 3 the redirect gets load balances to a different instance of > > tomcat, step 4 works fine (the request is read the the new session is got > > and the user info set on it). But this is when it gets really odd. Step 5 > > is executed fine, but when the home page is constructed > > our MetaDataRoleAuthorizationStrategy.isInstantiationAuthorized() is > > called as normal, and when we check the session to see if the users > details > > are ok, there is no user in the session at all and we have a different > > session ! > > > > Any ideas at all what is happening here? Did something change around the > > session handling? I'm wondering if its something to do with the 302 > > redirect to the new URL with parameters? > > > > many thanks > > >
Re: Wicket 6 Session issue
Hi, As far as I know the session replication supporting code is the same since Wicket 1.4.1 (or 1.4.2). The Wicket Session object is saved as an attribute in the HttpSession. The HttpSession is replicated by Tomcat itself. What is your Tomcat config related to replication ? Do you use sticky sessions ? It seems you don't but I have to ask. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Wed, Nov 5, 2014 at 12:43 PM, Wayne W wrote: > Hi, > > we recently migrated to 6.17 from 4.x. Something we are now experiencing is > an odd session problem in production. > > We have 2 tomcats load balance running the front end wicket code. We have a > certain flow that goes like this: > > >1. User goes to : my.example.com/login (LoginPage.java) >2. They log in >3. We invalidate the session and do a redirect to : > foo.example.com/login >passing some parameters >4. In the constructor of LoginPage we verify the parameters and if valid >setup up the new current session with the user's details >5. LoginPage then does >a setResponsePage(Application.get().getHomePage()); > > This on a single node/machine/instance of tomcat works great and with > Wicket 4 it also worked great in a 2 node/instance load balanced situation > however we have a problem. > > Problem: > If at step 3 the redirect gets load balances to a different instance of > tomcat, step 4 works fine (the request is read the the new session is got > and the user info set on it). But this is when it gets really odd. Step 5 > is executed fine, but when the home page is constructed > our MetaDataRoleAuthorizationStrategy.isInstantiationAuthorized() is > called as normal, and when we check the session to see if the users details > are ok, there is no user in the session at all and we have a different > session ! > > Any ideas at all what is happening here? Did something change around the > session handling? I'm wondering if its something to do with the 302 > redirect to the new URL with parameters? > > many thanks >
Wicket 6 Session issue
Hi, we recently migrated to 6.17 from 4.x. Something we are now experiencing is an odd session problem in production. We have 2 tomcats load balance running the front end wicket code. We have a certain flow that goes like this: 1. User goes to : my.example.com/login (LoginPage.java) 2. They log in 3. We invalidate the session and do a redirect to : foo.example.com/login passing some parameters 4. In the constructor of LoginPage we verify the parameters and if valid setup up the new current session with the user's details 5. LoginPage then does a setResponsePage(Application.get().getHomePage()); This on a single node/machine/instance of tomcat works great and with Wicket 4 it also worked great in a 2 node/instance load balanced situation however we have a problem. Problem: If at step 3 the redirect gets load balances to a different instance of tomcat, step 4 works fine (the request is read the the new session is got and the user info set on it). But this is when it gets really odd. Step 5 is executed fine, but when the home page is constructed our MetaDataRoleAuthorizationStrategy.isInstantiationAuthorized() is called as normal, and when we check the session to see if the users details are ok, there is no user in the session at all and we have a different session ! Any ideas at all what is happening here? Did something change around the session handling? I'm wondering if its something to do with the 302 redirect to the new URL with parameters? many thanks
