Re: IE 6 - 'Wicket' is undefined
Hi! > For all poor souls that may run into this problem here is a sanity > check to consider. > > Attempt to run the following URL: > http://yourmachinename[:port]/appRoot/resources/org.apache.wicket.ajax.WicketAjaxReference/wicket-ajax.js Interesting. It might be related to: http://apache-wicket.1842946.n4.nabble.com/Internal-error-parsing-wicket-interface-td3610746.html ** Martin > > Your browser should attempt downloading a file (in case of IE6 - > that's the default behavior) > > If you get error the problem in all likelihood lies with broken > deployment - which is pretty interesting in our case since the app > rendered on server side without issues but failed on the front end. > > I hope it helps. > > Thanks, > Dave > > On Fri, Jun 24, 2011 at 2:41 PM, Martin Makundi > wrote: >> Hi! >> >> It will probably cost you quite some time but you can debug the order >> of js library references being loaded in various situations. >> >> Wicket is a javascript reference to the wicket js methods and if >> "Wicket" is undefined it means it is not loaded at that time... for >> some reason. >> >> ** >> Martin >> >> >> 2011/6/24 D D : >>> Hello, >>> >>> We have an issue where IE6 loads and works fine with wicket's js >>> during development. As soon as we moved app to "community" server IE6 >>> comes up with an error: >>> >>> "Error: 'Wicket' is undefined >>> >>> As much as we would wish to get off IE6 we have to stick with it for a >>> little longer. I've seen people having issues after moving from 1.4.7 >>> to newer version. I've never seen resolution to a thread that we >>> running back in Nov. 2010. >>> >>> Does anyone have any idea what could have gone wrong? >>> >>> Thanks, >>> Dave >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: IE 6 - 'Wicket' is undefined
Thanks Dave, that's a good advice. Just out of curiosity: what did go wrong with your deployment? Best, Sven On 25.06.2011 04:26, D D wrote: For all poor souls that may run into this problem here is a sanity check to consider. Attempt to run the following URL: http://yourmachinename[:port]/appRoot/resources/org.apache.wicket.ajax.WicketAjaxReference/wicket-ajax.js Your browser should attempt downloading a file (in case of IE6 - that's the default behavior) If you get error the problem in all likelihood lies with broken deployment - which is pretty interesting in our case since the app rendered on server side without issues but failed on the front end. I hope it helps. Thanks, Dave On Fri, Jun 24, 2011 at 2:41 PM, Martin Makundi wrote: Hi! It will probably cost you quite some time but you can debug the order of js library references being loaded in various situations. Wicket is a javascript reference to the wicket js methods and if "Wicket" is undefined it means it is not loaded at that time... for some reason. ** Martin 2011/6/24 D D: Hello, We have an issue where IE6 loads and works fine with wicket's js during development. As soon as we moved app to "community" server IE6 comes up with an error: "Error: 'Wicket' is undefined As much as we would wish to get off IE6 we have to stick with it for a little longer. I've seen people having issues after moving from 1.4.7 to newer version. I've never seen resolution to a thread that we running back in Nov. 2010. Does anyone have any idea what could have gone wrong? Thanks, Dave - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
[Announce] Wicket 1.5-RC5.1 is released
The Wicket Team is proud to introduce the fifth Release Candidate in Wicket 1.5 series. It includes bug fixes and improvements reported against 1.5-RC4.2. See the changelog for full list. More detailed migration notes are available on our [Migrate to 1.5 Wiki Page](https://cwiki.apache.org/WICKET/migration-to-wicket-15.html) Release Artifacts: * Subversion tag: http://svn.apache.org/repos/asf/wicket/releases/wicket-1.5-RC5.1 * Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561&version=12316423 https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=project+%3D+WICKET+AND+fixVersion+%3D+%221.5-RC5.1%22 * To use in Maven: org.apache.wicket wicket-core 1.5-RC5.1 * Download the full distribution: http://www.apache.org/dyn/closer.cgi/wicket/1.5-RC5.1 (including source) The Wicket Team! - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: IE 6 - 'Wicket' is undefined
For all poor souls that may run into this problem here is a sanity check to consider. Attempt to run the following URL: http://yourmachinename[:port]/appRoot/resources/org.apache.wicket.ajax.WicketAjaxReference/wicket-ajax.js Your browser should attempt downloading a file (in case of IE6 - that's the default behavior) If you get error the problem in all likelihood lies with broken deployment - which is pretty interesting in our case since the app rendered on server side without issues but failed on the front end. I hope it helps. Thanks, Dave On Fri, Jun 24, 2011 at 2:41 PM, Martin Makundi wrote: > Hi! > > It will probably cost you quite some time but you can debug the order > of js library references being loaded in various situations. > > Wicket is a javascript reference to the wicket js methods and if > "Wicket" is undefined it means it is not loaded at that time... for > some reason. > > ** > Martin > > > 2011/6/24 D D : >> Hello, >> >> We have an issue where IE6 loads and works fine with wicket's js >> during development. As soon as we moved app to "community" server IE6 >> comes up with an error: >> >> "Error: 'Wicket' is undefined >> >> As much as we would wish to get off IE6 we have to stick with it for a >> little longer. I've seen people having issues after moving from 1.4.7 >> to newer version. I've never seen resolution to a thread that we >> running back in Nov. 2010. >> >> Does anyone have any idea what could have gone wrong? >> >> Thanks, >> Dave >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Check the markup in onBeforeRender
in 1.5 you can use getMarkup() and you can move your code to onMarkupAttached() -igor On Fri, Jun 24, 2011 at 12:39 PM, Adriano dos Santos Fernandes wrote: > Hi! > > I want to add some components to the hierarchy dynamically based on the > wicket:id presents in the HTML. > > Basically, I want to check if an used wicket:id was not explicitly added > (with add method) by the user and then (in some cases) add it. > > But I'm having trouble to do that. I tried with IComponentResolver, but then > I needed to use autoAdd but I can't afford the component being removed. > > So I'm trying in onBeforeRender, but how do I can query the markup to see > the list of child wicket:id's of a given component? > > > Adriano > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: IE 6 - 'Wicket' is undefined
Hi! It will probably cost you quite some time but you can debug the order of js library references being loaded in various situations. Wicket is a javascript reference to the wicket js methods and if "Wicket" is undefined it means it is not loaded at that time... for some reason. ** Martin 2011/6/24 D D : > Hello, > > We have an issue where IE6 loads and works fine with wicket's js > during development. As soon as we moved app to "community" server IE6 > comes up with an error: > > "Error: 'Wicket' is undefined > > As much as we would wish to get off IE6 we have to stick with it for a > little longer. I've seen people having issues after moving from 1.4.7 > to newer version. I've never seen resolution to a thread that we > running back in Nov. 2010. > > Does anyone have any idea what could have gone wrong? > > Thanks, > Dave > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Check the markup in onBeforeRender
Hi! I want to add some components to the hierarchy dynamically based on the wicket:id presents in the HTML. Basically, I want to check if an used wicket:id was not explicitly added (with add method) by the user and then (in some cases) add it. But I'm having trouble to do that. I tried with IComponentResolver, but then I needed to use autoAdd but I can't afford the component being removed. So I'm trying in onBeforeRender, but how do I can query the markup to see the list of child wicket:id's of a given component? Adriano - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
IE 6 - 'Wicket' is undefined
Hello, We have an issue where IE6 loads and works fine with wicket's js during development. As soon as we moved app to "community" server IE6 comes up with an error: "Error: 'Wicket' is undefined As much as we would wish to get off IE6 we have to stick with it for a little longer. I've seen people having issues after moving from 1.4.7 to newer version. I've never seen resolution to a thread that we running back in Nov. 2010. Does anyone have any idea what could have gone wrong? Thanks, Dave - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Sorting problem
It seems like an "instanceof String" followed by downcasts and
String#compareToIgnoreCase should do the trick.
On Fri, Jun 24, 2011 at 12:30 AM, pragya.rawal wrote:
> Hi,
>
> I have a DataView and I am sorting data column (on click of column header)
> inside it using my custom SortableTaskDataProvider which extends
> SortableDataProvider.
>
> So, I pass the property name (column) and DataView (list) and I get the
> list
> sorted on the basis of property.
>
> So, as per the default implementation of compareTo, it sorts Saring
> starting
> with Capital letters first and the the ones that start with lower case.
>
> I require to write a comparator which sorts irrespective of the case (upper
> or lower), but the problem I am facing is that the setSort() method
> provided
> by wicket takes the property name.
>
> Is there any way where I can specify that if the property is of type
> String,
> it should sort without considering the case.
>
> Below is my code for SortableTaskDataProvider
>
>
> public class SortableTaskDataProvider extends
> SortableDataProvider {
>
>private static final long serialVersionUID = 1L;
>private List list = new ArrayList();
>
>public SortableTaskDataProvider(List list) {
>super();
>setSort("createdBy", false);
>this.list = list;
>}
>
>@Override
>public Iterator iterator(int first, int count)
> {
>List newList = new ArrayList(list);
>
>Collections.sort(newList, new Comparator() {
>
>@SuppressWarnings("rawtypes")
>@Override
>public int compare(BaseTaskModel o1, BaseTaskModel o2) {
>PropertyModel model1 = new
> PropertyModel(o1, getSort().getProperty());
>PropertyModel model2 = new
> PropertyModel(o2, getSort().getProperty());
>
>@SuppressWarnings("unchecked")
>int result =
> model1.getObject().compareTo(model2.getObject());
>
>if (!getSort().isAscending()) {
>result = -result;
>}
>
>return result;
>
>}
>});
>return newList.subList(first, first + count).iterator();
>}
>
>@Override
>public int size() {
>if (list == null)
>return 0;
>return list.size();
>}
>
>@Override
>public IModel model(final BaseTaskModel object) {
>return new AbstractReadOnlyModel() {
>private static final long serialVersionUID = 1L;
>
>@Override
>public BaseTaskModel getObject() {
>return object;
>}
>};
>}
> }
>
>
> Any pointers will be highly appreciated.
>
> Thanks,
> Pragya
> http://pragyarawal.co.cc
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Sorting-problem-tp3621869p3621869.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: Column Filters
Hi, take a look at the fantastic :-) free chapter from Wicket Cookbook. It's about what are you doing with tables. http://www.google.com/url?sa=t&source=web&cd=5&ved=0CC8QFjAE&url=http%3A%2F%2Fwww.packtpub.com%2Fsites%2Fdefault%2Ffiles%2F1605OS-Chapter-5-Displaying-Data-Using-DataTable.pdf&ei=oW0ETvbYNsqr-QbK1KnYDQ&usg=AFQjCNHZ5N3Aj6hu_tgx752ZuZN-EUyHrw Hi, I have a requirement wherein I want to filter data in a DataView. I want a Microsoft Excel type filter wherein we select filter on a column(header) and it displays all the values in the column in a dropdown. Then I should select some value from that dropdown and I should get the data filtered on the basis of the value selected. Do we have any existing functionality supporting this? Or Can anyone plz point me about how I should proceed for this. Thanks, Pragya http://pragyarawal.co.cc -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Column-Filters-tp3621848p3621848.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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Render WebPage to String in Wicket 1.5
Hi,
I'd recommend to preserve the old reponse, use StrintResponse
temporarily, and at the end in finally{} restore the original
response.
On Fri, Jun 24, 2011 at 12:42 PM, Marco wrote:
> I need a second opinion about using Wickets template capabilities to send
> HTML emails from a Wicket web application.
>
> Situation:
> I create an instance of a WebPage which must rendered to a String. This
> String is then passed to JavaMail as payload of an email.
>
> The email is created and sent after submitting a Wicket form.
> The WebPage is rendered with the following method:
>
> public String renderTemplate(WebPage webPage) {
>
> BufferedWebResponse bufferedWebResponse = new BufferedWebResponse(null);
> webPage.getRequestCycle().setResponse(bufferedWebResponse);
> webPage.render();
>
> return bufferedWebResponse.getText().toString();
> }
>
> It works and in my opinion this is an elegant solution though I'm not too
> sure about it.
> In Wicket 1.4 I used more code to do the same:
> http://www.danwalmsley.com/2008/10/21/render-a-wicket-page-to-a-string-for-html-email/
>
> Am I missing something?
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Render-WebPage-to-String-in-Wicket-1-5-tp3622130p3622130.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
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Column Filters
Hi, I have a requirement wherein I want to filter data in a DataView. I want a Microsoft Excel type filter wherein we select filter on a column(header) and it displays all the values in the column in a dropdown. Then I should select some value from that dropdown and I should get the data filtered on the basis of the value selected. Do we have any existing functionality supporting this? Or Can anyone plz point me about how I should proceed for this. Thanks, Pragya http://pragyarawal.co.cc -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Column-Filters-tp3621848p3621848.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
Sorting problem
Hi,
I have a DataView and I am sorting data column (on click of column header)
inside it using my custom SortableTaskDataProvider which extends
SortableDataProvider.
So, I pass the property name (column) and DataView (list) and I get the list
sorted on the basis of property.
So, as per the default implementation of compareTo, it sorts Saring starting
with Capital letters first and the the ones that start with lower case.
I require to write a comparator which sorts irrespective of the case (upper
or lower), but the problem I am facing is that the setSort() method provided
by wicket takes the property name.
Is there any way where I can specify that if the property is of type String,
it should sort without considering the case.
Below is my code for SortableTaskDataProvider
public class SortableTaskDataProvider extends
SortableDataProvider {
private static final long serialVersionUID = 1L;
private List list = new ArrayList();
public SortableTaskDataProvider(List list) {
super();
setSort("createdBy", false);
this.list = list;
}
@Override
public Iterator iterator(int first, int count)
{
List newList = new ArrayList(list);
Collections.sort(newList, new Comparator() {
@SuppressWarnings("rawtypes")
@Override
public int compare(BaseTaskModel o1, BaseTaskModel o2) {
PropertyModel model1 = new
PropertyModel(o1, getSort().getProperty());
PropertyModel model2 = new
PropertyModel(o2, getSort().getProperty());
@SuppressWarnings("unchecked")
int result =
model1.getObject().compareTo(model2.getObject());
if (!getSort().isAscending()) {
result = -result;
}
return result;
}
});
return newList.subList(first, first + count).iterator();
}
@Override
public int size() {
if (list == null)
return 0;
return list.size();
}
@Override
public IModel model(final BaseTaskModel object) {
return new AbstractReadOnlyModel() {
private static final long serialVersionUID = 1L;
@Override
public BaseTaskModel getObject() {
return object;
}
};
}
}
Any pointers will be highly appreciated.
Thanks,
Pragya
http://pragyarawal.co.cc
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Sorting-problem-tp3621869p3621869.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
Render WebPage to String in Wicket 1.5
I need a second opinion about using Wickets template capabilities to send
HTML emails from a Wicket web application.
Situation:
I create an instance of a WebPage which must rendered to a String. This
String is then passed to JavaMail as payload of an email.
The email is created and sent after submitting a Wicket form.
The WebPage is rendered with the following method:
public String renderTemplate(WebPage webPage) {
BufferedWebResponse bufferedWebResponse = new BufferedWebResponse(null);
webPage.getRequestCycle().setResponse(bufferedWebResponse);
webPage.render();
return bufferedWebResponse.getText().toString();
}
It works and in my opinion this is an elegant solution though I'm not too
sure about it.
In Wicket 1.4 I used more code to do the same:
http://www.danwalmsley.com/2008/10/21/render-a-wicket-page-to-a-string-for-html-email/
Am I missing something?
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Render-WebPage-to-String-in-Wicket-1-5-tp3622130p3622130.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 and OSGi
Looks simpler solution. If it works OK then we can commit it in SVN.
You are right, wicket-bundle just combines -util.jar, -request.jar and
-core.jar into one.
We can create a new wicket-osgi project in wicketstuff that will
provide the integration code, like OsgiClassResolver and whatever else
is needed.
On Fri, Jun 24, 2011 at 11:22 AM, Brian Topping wrote:
> wicket-bundle appears to be simply using assembly plugin to mash all the jars
> together.
>
> I haven't tested it yet, but I believe
> https://github.com/topping/wicket/commit/b120bdd4e6b7b085f2644aab1f77b3d40558c967
> is a better solution.
>
> Haven't found OsgiClassResolver yet, but it's late here and I'm going to bed.
>
> On Jun 24, 2011, at 12:50 AM, Martin Grigorov wrote:
>
>> OsgiClassResolver will be in wicket-bundle.jar (the one in wicketstuff).
>> The user application will use it by:
>>
>> MyApp#init() {
>> super.init();
>> getApplicationSettings.setClassResolver(new OsgiClassResolver());
>> }
>>
>>
>> On Fri, Jun 24, 2011 at 10:46 AM, Brian Topping wrote:
>>> If by that you mean Wicket would be injected with something like the system
>>> classloader or wicket's classloader, it kind of breaks modularity. How
>>> would one upgrade wicket itself? There's no limitation to doing so, the
>>> new Wicket bundle can have dependencies in parallel with the old wicket
>>> bundle, but if the dependencies were holding on to the old wicket's
>>> classloader, seems like a problem.
>>>
>>> On Jun 24, 2011, at 12:39 AM, David Leangen wrote:
>>>
IIUC, other frameworks allow for the injection of a classloader. Wouldn't
that be enough?
We could then package an optional classloader just for that purpose.
Cheers,
=David
On Jun 24, 2011, at 4:34 PM, Brian Topping wrote:
> It seems that Wicket should not be burdened with this tracking that is
> only used in OSGi configurations. Another issue is that an admin will
> use OSGi interfaces to swap out bundles, not wicket interfaces. OSGi is
> going to use the BundleActivator of the component bundle to stop it, and
> it won't know to tell the wicket core service anything about what it's
> doing to the component bundle. Thus it needs to know whether and/or when
> it can unload.
>
> Once a bundle is in the STOPPING state, it's no longer an active service,
> so it cannot call other services or be called by them. Yet, the tracking
> needs to be updated so the blocked call to stop can unblock, hence the
> weak reference collection.
>
> On Jun 23, 2011, at 8:05 PM, Igor Vaynberg wrote:
>
>> i think the frameworks should track this. this way wicket can track
>> what it is serializing and when it is letting it go. jetty can keep
>> track of what it has in its http session.
>>
>> the serialization bundle should provide a way for bundles to tell it
>> "i am holding on to class A from bundle B" and i no longer care about
>> class C from bundle D"
>>
>> -igor
>>
>> On Thu, Jun 23, 2011 at 6:48 PM, Brian Topping
>> wrote:
>>> Good point. This could be handled by the serializer maintaining a
>>> WeakHashMap of the sessions that use a particular bundle and blocking
>>> in the bundle activator's stop method until the list is empty.
>>>
>>> But if a user was busy for an extended period, like some kind of
>>> automated scraper or monitor that ended up having the session open for
>>> days, the check would have to be more granular than the session. Which
>>> seems like it's going to be different between 1.4 and 1.5 because of
>>> the migration from pagemaps.
>>>
>>> On Jun 23, 2011, at 4:41 PM, Igor Vaynberg wrote:
>>>
something else to consider - where this gets even hairier :)
user accesses a page that has a component from bundle A, the page is
serialized.
admin upgrades bundle A which has a new version of the component -
that is not compatible serialization-wise
user click back and the page needs to be serialized - error
what is needed here i some way to veto a bundle/version removal until
all web sessions that access components in those bundles have timed
out. this is not really wicket-specific, more web specific as web apps
can stick objects into http session...
-igor
On Thu, Jun 23, 2011 at 4:30 PM, Brian Topping
wrote:
>
> On Jun 23, 2011, at 10:11 AM, Harald Wellmann wrote:
>
>>> what is really needed here is someone taking the time to build a
>>> generic serialization mechanism for osgi. wicket's serialization is
>>> pluggable so it can be hooked into that.
>>>
>>
>> I'll take a look at the patches, play around with the code and find
>>>
Re: Wicket and OSGi
wicket-bundle appears to be simply using assembly plugin to mash all the jars
together.
I haven't tested it yet, but I believe
https://github.com/topping/wicket/commit/b120bdd4e6b7b085f2644aab1f77b3d40558c967
is a better solution.
Haven't found OsgiClassResolver yet, but it's late here and I'm going to bed.
On Jun 24, 2011, at 12:50 AM, Martin Grigorov wrote:
> OsgiClassResolver will be in wicket-bundle.jar (the one in wicketstuff).
> The user application will use it by:
>
> MyApp#init() {
> super.init();
> getApplicationSettings.setClassResolver(new OsgiClassResolver());
> }
>
>
> On Fri, Jun 24, 2011 at 10:46 AM, Brian Topping wrote:
>> If by that you mean Wicket would be injected with something like the system
>> classloader or wicket's classloader, it kind of breaks modularity. How
>> would one upgrade wicket itself? There's no limitation to doing so, the new
>> Wicket bundle can have dependencies in parallel with the old wicket bundle,
>> but if the dependencies were holding on to the old wicket's classloader,
>> seems like a problem.
>>
>> On Jun 24, 2011, at 12:39 AM, David Leangen wrote:
>>
>>>
>>> IIUC, other frameworks allow for the injection of a classloader. Wouldn't
>>> that be enough?
>>>
>>> We could then package an optional classloader just for that purpose.
>>>
>>>
>>> Cheers,
>>> =David
>>>
>>>
>>>
>>> On Jun 24, 2011, at 4:34 PM, Brian Topping wrote:
>>>
It seems that Wicket should not be burdened with this tracking that is
only used in OSGi configurations. Another issue is that an admin will use
OSGi interfaces to swap out bundles, not wicket interfaces. OSGi is going
to use the BundleActivator of the component bundle to stop it, and it
won't know to tell the wicket core service anything about what it's doing
to the component bundle. Thus it needs to know whether and/or when it can
unload.
Once a bundle is in the STOPPING state, it's no longer an active service,
so it cannot call other services or be called by them. Yet, the tracking
needs to be updated so the blocked call to stop can unblock, hence the
weak reference collection.
On Jun 23, 2011, at 8:05 PM, Igor Vaynberg wrote:
> i think the frameworks should track this. this way wicket can track
> what it is serializing and when it is letting it go. jetty can keep
> track of what it has in its http session.
>
> the serialization bundle should provide a way for bundles to tell it
> "i am holding on to class A from bundle B" and i no longer care about
> class C from bundle D"
>
> -igor
>
> On Thu, Jun 23, 2011 at 6:48 PM, Brian Topping
> wrote:
>> Good point. This could be handled by the serializer maintaining a
>> WeakHashMap of the sessions that use a particular bundle and blocking in
>> the bundle activator's stop method until the list is empty.
>>
>> But if a user was busy for an extended period, like some kind of
>> automated scraper or monitor that ended up having the session open for
>> days, the check would have to be more granular than the session. Which
>> seems like it's going to be different between 1.4 and 1.5 because of the
>> migration from pagemaps.
>>
>> On Jun 23, 2011, at 4:41 PM, Igor Vaynberg wrote:
>>
>>> something else to consider - where this gets even hairier :)
>>>
>>> user accesses a page that has a component from bundle A, the page is
>>> serialized.
>>> admin upgrades bundle A which has a new version of the component -
>>> that is not compatible serialization-wise
>>> user click back and the page needs to be serialized - error
>>>
>>> what is needed here i some way to veto a bundle/version removal until
>>> all web sessions that access components in those bundles have timed
>>> out. this is not really wicket-specific, more web specific as web apps
>>> can stick objects into http session...
>>>
>>> -igor
>>>
>>>
>>> On Thu, Jun 23, 2011 at 4:30 PM, Brian Topping
>>> wrote:
On Jun 23, 2011, at 10:11 AM, Harald Wellmann wrote:
>> what is really needed here is someone taking the time to build a
>> generic serialization mechanism for osgi. wicket's serialization is
>> pluggable so it can be hooked into that.
>>
>
> I'll take a look at the patches, play around with the code and find
> out if I'm one the wrong track or not... If I end up with anything
> interesting enough, I'll get back or attach another patch.
I'm also taking a look at it.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
Re: Wicket and OSGi
OsgiClassResolver will be in wicket-bundle.jar (the one in wicketstuff).
The user application will use it by:
MyApp#init() {
super.init();
getApplicationSettings.setClassResolver(new OsgiClassResolver());
}
On Fri, Jun 24, 2011 at 10:46 AM, Brian Topping wrote:
> If by that you mean Wicket would be injected with something like the system
> classloader or wicket's classloader, it kind of breaks modularity. How would
> one upgrade wicket itself? There's no limitation to doing so, the new Wicket
> bundle can have dependencies in parallel with the old wicket bundle, but if
> the dependencies were holding on to the old wicket's classloader, seems like
> a problem.
>
> On Jun 24, 2011, at 12:39 AM, David Leangen wrote:
>
>>
>> IIUC, other frameworks allow for the injection of a classloader. Wouldn't
>> that be enough?
>>
>> We could then package an optional classloader just for that purpose.
>>
>>
>> Cheers,
>> =David
>>
>>
>>
>> On Jun 24, 2011, at 4:34 PM, Brian Topping wrote:
>>
>>> It seems that Wicket should not be burdened with this tracking that is only
>>> used in OSGi configurations. Another issue is that an admin will use OSGi
>>> interfaces to swap out bundles, not wicket interfaces. OSGi is going to
>>> use the BundleActivator of the component bundle to stop it, and it won't
>>> know to tell the wicket core service anything about what it's doing to the
>>> component bundle. Thus it needs to know whether and/or when it can unload.
>>>
>>> Once a bundle is in the STOPPING state, it's no longer an active service,
>>> so it cannot call other services or be called by them. Yet, the tracking
>>> needs to be updated so the blocked call to stop can unblock, hence the weak
>>> reference collection.
>>>
>>> On Jun 23, 2011, at 8:05 PM, Igor Vaynberg wrote:
>>>
i think the frameworks should track this. this way wicket can track
what it is serializing and when it is letting it go. jetty can keep
track of what it has in its http session.
the serialization bundle should provide a way for bundles to tell it
"i am holding on to class A from bundle B" and i no longer care about
class C from bundle D"
-igor
On Thu, Jun 23, 2011 at 6:48 PM, Brian Topping
wrote:
> Good point. This could be handled by the serializer maintaining a
> WeakHashMap of the sessions that use a particular bundle and blocking in
> the bundle activator's stop method until the list is empty.
>
> But if a user was busy for an extended period, like some kind of
> automated scraper or monitor that ended up having the session open for
> days, the check would have to be more granular than the session. Which
> seems like it's going to be different between 1.4 and 1.5 because of the
> migration from pagemaps.
>
> On Jun 23, 2011, at 4:41 PM, Igor Vaynberg wrote:
>
>> something else to consider - where this gets even hairier :)
>>
>> user accesses a page that has a component from bundle A, the page is
>> serialized.
>> admin upgrades bundle A which has a new version of the component -
>> that is not compatible serialization-wise
>> user click back and the page needs to be serialized - error
>>
>> what is needed here i some way to veto a bundle/version removal until
>> all web sessions that access components in those bundles have timed
>> out. this is not really wicket-specific, more web specific as web apps
>> can stick objects into http session...
>>
>> -igor
>>
>>
>> On Thu, Jun 23, 2011 at 4:30 PM, Brian Topping
>> wrote:
>>>
>>> On Jun 23, 2011, at 10:11 AM, Harald Wellmann wrote:
>>>
> what is really needed here is someone taking the time to build a
> generic serialization mechanism for osgi. wicket's serialization is
> pluggable so it can be hooked into that.
>
I'll take a look at the patches, play around with the code and find
out if I'm one the wrong track or not... If I end up with anything
interesting enough, I'll get back or attach another patch.
>>>
>>> I'm also taking a look at it.
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
Re: Wicket and OSGi
If by that you mean Wicket would be injected with something like the system classloader or wicket's classloader, it kind of breaks modularity. How would one upgrade wicket itself? There's no limitation to doing so, the new Wicket bundle can have dependencies in parallel with the old wicket bundle, but if the dependencies were holding on to the old wicket's classloader, seems like a problem. On Jun 24, 2011, at 12:39 AM, David Leangen wrote: > > IIUC, other frameworks allow for the injection of a classloader. Wouldn't > that be enough? > > We could then package an optional classloader just for that purpose. > > > Cheers, > =David > > > > On Jun 24, 2011, at 4:34 PM, Brian Topping wrote: > >> It seems that Wicket should not be burdened with this tracking that is only >> used in OSGi configurations. Another issue is that an admin will use OSGi >> interfaces to swap out bundles, not wicket interfaces. OSGi is going to use >> the BundleActivator of the component bundle to stop it, and it won't know to >> tell the wicket core service anything about what it's doing to the component >> bundle. Thus it needs to know whether and/or when it can unload. >> >> Once a bundle is in the STOPPING state, it's no longer an active service, so >> it cannot call other services or be called by them. Yet, the tracking needs >> to be updated so the blocked call to stop can unblock, hence the weak >> reference collection. >> >> On Jun 23, 2011, at 8:05 PM, Igor Vaynberg wrote: >> >>> i think the frameworks should track this. this way wicket can track >>> what it is serializing and when it is letting it go. jetty can keep >>> track of what it has in its http session. >>> >>> the serialization bundle should provide a way for bundles to tell it >>> "i am holding on to class A from bundle B" and i no longer care about >>> class C from bundle D" >>> >>> -igor >>> >>> On Thu, Jun 23, 2011 at 6:48 PM, Brian Topping wrote: Good point. This could be handled by the serializer maintaining a WeakHashMap of the sessions that use a particular bundle and blocking in the bundle activator's stop method until the list is empty. But if a user was busy for an extended period, like some kind of automated scraper or monitor that ended up having the session open for days, the check would have to be more granular than the session. Which seems like it's going to be different between 1.4 and 1.5 because of the migration from pagemaps. On Jun 23, 2011, at 4:41 PM, Igor Vaynberg wrote: > something else to consider - where this gets even hairier :) > > user accesses a page that has a component from bundle A, the page is > serialized. > admin upgrades bundle A which has a new version of the component - > that is not compatible serialization-wise > user click back and the page needs to be serialized - error > > what is needed here i some way to veto a bundle/version removal until > all web sessions that access components in those bundles have timed > out. this is not really wicket-specific, more web specific as web apps > can stick objects into http session... > > -igor > > > On Thu, Jun 23, 2011 at 4:30 PM, Brian Topping > wrote: >> >> On Jun 23, 2011, at 10:11 AM, Harald Wellmann wrote: >> what is really needed here is someone taking the time to build a generic serialization mechanism for osgi. wicket's serialization is pluggable so it can be hooked into that. >>> >>> I'll take a look at the patches, play around with the code and find out >>> if I'm one the wrong track or not... If I end up with anything >>> interesting enough, I'll get back or attach another patch. >> >> I'm also taking a look at it. >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apac
Re: Wicket and OSGi
Wicket has org.apache.wicket.application.IClassResolver. The mentioned ticket earlier has OsgiClassResolver impl On Fri, Jun 24, 2011 at 10:39 AM, David Leangen wrote: > > IIUC, other frameworks allow for the injection of a classloader. Wouldn't > that be enough? > > We could then package an optional classloader just for that purpose. > > > Cheers, > =David > > > > On Jun 24, 2011, at 4:34 PM, Brian Topping wrote: > >> It seems that Wicket should not be burdened with this tracking that is only >> used in OSGi configurations. Another issue is that an admin will use OSGi >> interfaces to swap out bundles, not wicket interfaces. OSGi is going to use >> the BundleActivator of the component bundle to stop it, and it won't know to >> tell the wicket core service anything about what it's doing to the component >> bundle. Thus it needs to know whether and/or when it can unload. >> >> Once a bundle is in the STOPPING state, it's no longer an active service, so >> it cannot call other services or be called by them. Yet, the tracking needs >> to be updated so the blocked call to stop can unblock, hence the weak >> reference collection. >> >> On Jun 23, 2011, at 8:05 PM, Igor Vaynberg wrote: >> >>> i think the frameworks should track this. this way wicket can track >>> what it is serializing and when it is letting it go. jetty can keep >>> track of what it has in its http session. >>> >>> the serialization bundle should provide a way for bundles to tell it >>> "i am holding on to class A from bundle B" and i no longer care about >>> class C from bundle D" >>> >>> -igor >>> >>> On Thu, Jun 23, 2011 at 6:48 PM, Brian Topping wrote: Good point. This could be handled by the serializer maintaining a WeakHashMap of the sessions that use a particular bundle and blocking in the bundle activator's stop method until the list is empty. But if a user was busy for an extended period, like some kind of automated scraper or monitor that ended up having the session open for days, the check would have to be more granular than the session. Which seems like it's going to be different between 1.4 and 1.5 because of the migration from pagemaps. On Jun 23, 2011, at 4:41 PM, Igor Vaynberg wrote: > something else to consider - where this gets even hairier :) > > user accesses a page that has a component from bundle A, the page is > serialized. > admin upgrades bundle A which has a new version of the component - > that is not compatible serialization-wise > user click back and the page needs to be serialized - error > > what is needed here i some way to veto a bundle/version removal until > all web sessions that access components in those bundles have timed > out. this is not really wicket-specific, more web specific as web apps > can stick objects into http session... > > -igor > > > On Thu, Jun 23, 2011 at 4:30 PM, Brian Topping > wrote: >> >> On Jun 23, 2011, at 10:11 AM, Harald Wellmann wrote: >> what is really needed here is someone taking the time to build a generic serialization mechanism for osgi. wicket's serialization is pluggable so it can be hooked into that. >>> >>> I'll take a look at the patches, play around with the code and find out >>> if I'm one the wrong track or not... If I end up with anything >>> interesting enough, I'll get back or attach another patch. >> >> I'm also taking a look at it. >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: Wicket and OSGi
On Jun 23, 2011, at 11:09 PM, Martin Grigorov wrote: > This sounds like the problem solved with > http://www.tomcatexpert.com/blog/2011/05/31/parallel-deployment-tomcat-7 Kind of assumes one is using Tomcat and not one of the other ways to deploy a web application with OSGi. :-) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and OSGi
IIUC, other frameworks allow for the injection of a classloader. Wouldn't that be enough? We could then package an optional classloader just for that purpose. Cheers, =David On Jun 24, 2011, at 4:34 PM, Brian Topping wrote: > It seems that Wicket should not be burdened with this tracking that is only > used in OSGi configurations. Another issue is that an admin will use OSGi > interfaces to swap out bundles, not wicket interfaces. OSGi is going to use > the BundleActivator of the component bundle to stop it, and it won't know to > tell the wicket core service anything about what it's doing to the component > bundle. Thus it needs to know whether and/or when it can unload. > > Once a bundle is in the STOPPING state, it's no longer an active service, so > it cannot call other services or be called by them. Yet, the tracking needs > to be updated so the blocked call to stop can unblock, hence the weak > reference collection. > > On Jun 23, 2011, at 8:05 PM, Igor Vaynberg wrote: > >> i think the frameworks should track this. this way wicket can track >> what it is serializing and when it is letting it go. jetty can keep >> track of what it has in its http session. >> >> the serialization bundle should provide a way for bundles to tell it >> "i am holding on to class A from bundle B" and i no longer care about >> class C from bundle D" >> >> -igor >> >> On Thu, Jun 23, 2011 at 6:48 PM, Brian Topping wrote: >>> Good point. This could be handled by the serializer maintaining a >>> WeakHashMap of the sessions that use a particular bundle and blocking in >>> the bundle activator's stop method until the list is empty. >>> >>> But if a user was busy for an extended period, like some kind of automated >>> scraper or monitor that ended up having the session open for days, the >>> check would have to be more granular than the session. Which seems like >>> it's going to be different between 1.4 and 1.5 because of the migration >>> from pagemaps. >>> >>> On Jun 23, 2011, at 4:41 PM, Igor Vaynberg wrote: >>> something else to consider - where this gets even hairier :) user accesses a page that has a component from bundle A, the page is serialized. admin upgrades bundle A which has a new version of the component - that is not compatible serialization-wise user click back and the page needs to be serialized - error what is needed here i some way to veto a bundle/version removal until all web sessions that access components in those bundles have timed out. this is not really wicket-specific, more web specific as web apps can stick objects into http session... -igor On Thu, Jun 23, 2011 at 4:30 PM, Brian Topping wrote: > > On Jun 23, 2011, at 10:11 AM, Harald Wellmann wrote: > >>> what is really needed here is someone taking the time to build a >>> generic serialization mechanism for osgi. wicket's serialization is >>> pluggable so it can be hooked into that. >>> >> >> I'll take a look at the patches, play around with the code and find out >> if I'm one the wrong track or not... If I end up with anything >> interesting enough, I'll get back or attach another patch. > > I'm also taking a look at it. > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and OSGi
It seems that Wicket should not be burdened with this tracking that is only used in OSGi configurations. Another issue is that an admin will use OSGi interfaces to swap out bundles, not wicket interfaces. OSGi is going to use the BundleActivator of the component bundle to stop it, and it won't know to tell the wicket core service anything about what it's doing to the component bundle. Thus it needs to know whether and/or when it can unload. Once a bundle is in the STOPPING state, it's no longer an active service, so it cannot call other services or be called by them. Yet, the tracking needs to be updated so the blocked call to stop can unblock, hence the weak reference collection. On Jun 23, 2011, at 8:05 PM, Igor Vaynberg wrote: > i think the frameworks should track this. this way wicket can track > what it is serializing and when it is letting it go. jetty can keep > track of what it has in its http session. > > the serialization bundle should provide a way for bundles to tell it > "i am holding on to class A from bundle B" and i no longer care about > class C from bundle D" > > -igor > > On Thu, Jun 23, 2011 at 6:48 PM, Brian Topping wrote: >> Good point. This could be handled by the serializer maintaining a >> WeakHashMap of the sessions that use a particular bundle and blocking in the >> bundle activator's stop method until the list is empty. >> >> But if a user was busy for an extended period, like some kind of automated >> scraper or monitor that ended up having the session open for days, the check >> would have to be more granular than the session. Which seems like it's >> going to be different between 1.4 and 1.5 because of the migration from >> pagemaps. >> >> On Jun 23, 2011, at 4:41 PM, Igor Vaynberg wrote: >> >>> something else to consider - where this gets even hairier :) >>> >>> user accesses a page that has a component from bundle A, the page is >>> serialized. >>> admin upgrades bundle A which has a new version of the component - >>> that is not compatible serialization-wise >>> user click back and the page needs to be serialized - error >>> >>> what is needed here i some way to veto a bundle/version removal until >>> all web sessions that access components in those bundles have timed >>> out. this is not really wicket-specific, more web specific as web apps >>> can stick objects into http session... >>> >>> -igor >>> >>> >>> On Thu, Jun 23, 2011 at 4:30 PM, Brian Topping wrote: On Jun 23, 2011, at 10:11 AM, Harald Wellmann wrote: >> what is really needed here is someone taking the time to build a >> generic serialization mechanism for osgi. wicket's serialization is >> pluggable so it can be hooked into that. >> > > I'll take a look at the patches, play around with the code and find out > if I'm one the wrong track or not... If I end up with anything > interesting enough, I'll get back or attach another patch. I'm also taking a look at it. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: regarding wicketstuff push
Hey seb , thanks for the quick fix ! On Fri, Jun 24, 2011 at 5:01 AM, Sebastian wrote: > hi vineet, > > you are right. this is probably a left over from the refactoring we did. I > just fixed it on github. > > regards, > > seb > > On 23.06.2011 22:58, vineet semwal wrote: >> >> hellos ! >> >> i was just looking at wicketstuff push and i saw a lot of changes in >> api and other improvements are done ,thanks for all that ! :) >> as very new to the new push, could not understand the below channel >> creation call.. >> >> public IPushChannel createChannel(final >> EventType event, final String label) >> >> why does a new channel creation needs event ? >> >> i have also looked at the code i noticed "event" is just not used in >> the channel creation method in AbstractPushService :| >> >> i think method declaration can be improved or may be i am missing >> something ?? >> >> >> > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- thank you, regards, Vineet Semwal - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
