we could stick with META-INF but change the file to just wicket.properties.
that would include a list of initializers for the archive:
library-initializer=<classname>
AppName-library-initializer=<classname>
how's that? now eclipse can do refactoring, it's expansible, it's all
on the java side.
Johan Compagner wrote:
that is something we also could use yes..
We have to see how we are storing inside it and how we can read this
easy.
There are or could be problems by using manifest files they could get
very crowded (if you for example use signing)
Martijn Dashorst wrote:
Just as a side note. I was thinking how Oscar does this. They
basically have the same problem: how to find which things a bundle
exports. They have created two things for auto-registration to take
place:
- add meta data to the MANIFEST.MF file in the JAR. They explicitly
set an Activator classname in the MANIFEST.MF, which is then
instantiated
- the Activator class (user supplied) then registers the bundle
services with the Oscar registry.
This is a rather neat interface I think. It puts configuration back
into the Java, and doesn't introduce another file and fileformat into
the game.
I'm not saying this is any good, but it is an option.
Martijn
Johan Compagner wrote:
no hate that
then i prefer the current one
just lines of classes..
Why again some xml tags around it?
I think room for future i not needed.
If we introduce something else then i still want to go very quickly
to java code
So what we can do then is use the same file
But check what the class implements and call that interface method
johan
Igor Vaynberg wrote:
You know guys, working with wicket ive been going through
xml-withdrawl, so
maybe this is a good place to introduce some xml!!!!
<wicket-bootstrap>
<component-initializers>
<component-initializer>com.foo.class1</component-initializer>
<component-initializer>com.fool.class2</component-initializer>
</component-initializers>
<room for future expansion/>
</wicket-bootstrap>
This is way better then com.foo.class1,com.foo.class2!!!
-Igor
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jonathan Locke
Sent: Thursday, August 11, 2005 2:27 PM
To: [email protected]
Subject: Re: [Wicket-develop] feedback refactor and paging navigation
true.
the name came from "wicket-" to identify the META-INF file as
wicket-related, followed by "component-initializers" to identify
that the components in the file implement IComponentInitializer,
followed by ".txt" to allow the file to be opened in notepad or
whatever by just clicking on it. i'm not saying this is ideal.
it's just how it is right now.
if we want to move to a properties file, we could go for this
instead:
wicket.properties:
components=wicket.Foo,wicket.Bar,...
we'd of course search for <AppName-wicket.properties> as well.
that would allow us to expand the usage beyond just initializing
components if we ever needed something like that...
it might be prudent to do it this way...
Johan Compagner wrote:
it is not really a properties file. A property file is
something like:
xxx=yyyy
johan
Cameron Braid wrote:
It looks to me like there is no other way.
I'm not so bothered by a single text file that contains a list
of classnames.
Why is it called wicket-component-initializers.txt ?
I think the .txt extension is a bad idea. Since if I use
eclipse to
refactor classes - I usually get it to scan for fully
quanified class
names in .properties files (and .xml files) Would it be a
bade idea
to use the.properties extension ?
Cameron
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:wicket-develop-
[EMAIL PROTECTED] On Behalf Of Johan Compagner
Sent: Friday, 12 August 2005 6:32 AM
To: [email protected]
Subject: Re: [Wicket-develop] feedback refactor and paging
navigation
I don't think there is a standard way.
We could test if the ClassLoader was a URLClassLoader
(and then call
getUrls() on it)
But this doesn't have to be the case i think..
Also File.list() can't work on a classloader. Because
you
don't have
a dir (you could have but you could have anything)
johanm
Cameron Braid wrote:
One other issue that comes to mind - where would the
classpath list
of jars/folders come from - since we can't rely on
System.getProperty("java.class.path") from within
servlet containers.
Is
there a standard way to obtain the servlet context's classpath ?
Cameron
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:wicket-
develop-
[EMAIL PROTECTED] On Behalf Of Gili
Sent: Friday, 12 August 2005 6:21 AM
To: [email protected]
Subject: Re: [Wicket-develop] feedback refactor and paging
navigation
Good point. So going back to the original proposal,
it sounds
like it'll be very fast if we use
File.listFiles(FilenameFilter).
Gili
Cameron Braid wrote:
This would be worse - you would still need to scan all jars
/ folders
on
the
class path - then for any filename ending in .class -
you would
have
to
do
Class.forName() which will load the class - thereby
loading EVERY
class
on
the classpath - not a good idea.
Cameron
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:wicket-
develop-
[EMAIL PROTECTED] On Behalf Of Gili
Sent: Friday, 12 August 2005 6:06 AM
To: [email protected]
Subject: Re: [Wicket-develop] feedback refactor and paging
navigation
Taking one step further... would it be possible
to drop the
resource file altogether and use pure reflection?
Specifically,
we search the classpath for classes which implement
interface IComponentInitializer and if so we assume they
contribute resources and invoke their
init(Application) method.
Cameron is right that someone should profile this but I
think this is ideal in that it is truely object oriented
and zero-configuration --
and
it is a one-time cost at startup.
Gili
Cameron Braid wrote:
This would mean searching every sub-directory of every
classpath
entry
(i.e.
jars and folders)
This will have a performance impact on the startup time of
wicket -
how
large - I dunno - someone cart to implement and profile ?
If the performance hit is insignificant - I think
this is the
better
way
to
do it. Although - why not name the file
ComponentClassName.wicket
:)
Cheers,
Cameron.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:wicket-
develop-
[EMAIL PROTECTED] On Behalf Of Gili
Sent: Friday, 12 August 2005 5:10 AM
To: [email protected]
Subject: Re: [Wicket-develop] feedback refactor and paging
navigation
I'm +1 on Igor's proposal (.resource files) because
amongst
other
things, it'll allow you to merge multiple JAR files
into one
easily (should you wish to do such a thing) and ship a
JAR with a whole
bunch
of related components as opposed to having to have
a different
JAR
for
each component. Right now you'd have to merge the META-INF/
resource
file by hand. Also, obfuscators such as Proguard will
automatically
do
this sort of JAR file merging and "shrinking" but
will not be
able
to
handle merging these META-INF files. Anyway... just food for
thought.
Gili
Jonathan Locke wrote:
sorry. didn't mean to jump on you, igor. i just
wanted to
make
sure
we
didn't throw
out something that's worth keeping... because there
have been
some
problems with
resources, a lot of people have been clamoring to
change the
whole plan. since i've been the one behind the
current plan
and wrote most or all of the
code
for it, i have
been trying to explain why i wrote it that way. it's
not perfect
for
sure (nothing ever is!),
but i think the basic idea is not only not broken, but it's
actually
pretty solid... especially
with the fixes we did last night.
i agree about the init thing, but i think that
Classloader.getResources() would have to be enhanced to
do this... not 100% sure though... if there's a
reasonable way
to do this, we should look into it.
Igor Vaynberg wrote:
Yes I see Jon. Thank you for a very long and detailed
explanation
as
to why
my idea sucked. I still think there is some room for
improvement
in
the
current situation. Cant we do a saerch through avail
packages
looking
for a
.resources file (im not sure how this would be done).
It would be nice to simply have
DatePicker.resources side by
side
with
DatePicker.java. It would eliminate refactoring
headaches at
least
as
far as
the package names go and it wouldn't be sitting in some
separate
folder.
-Igor
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Jonathan Locke
Sent: Thursday, August 11, 2005 1:17 AM
To: [email protected]
Subject: Re: [Wicket-develop] feedback refactor
and paging
navigation
actually it's not just that the service
registration info
has to
be
put somewhere, it's that a client component
that's using a
service
to
create a dynamic resource like, for example,
some kind of
panel
that
wants a dynamic button image created...
/that component/ would have to be able to create
its images
/when
the
app starts/ (because of clustering and server
restarts).
and
/only
the panel component itself/ can or should know
about this
/and/
it
has to be done on startup. wicket's resource handling
classes are already fully featured, object-oriented
"services" (but less vague and more OO powerful)
by virtue
of the fact that they
implement
the IResourceListener interface and respond to
requests for
resources
(ANY resource). so i just don't see any value at all
in this
service
concept beyond what we've already got. in fact,
i think it
would
significantly /subtract/ from wicket's existing
support for
dynamic
resources (think "service" if you prefer)... and
again, even if
we
did change the world, it wouldn't solve the bootstrapping
problem
we
have for components.
Johan Compagner wrote:
how does a component with a dynamically
generated image
make
that
image available in your scheme?
the component has to register the image with the
service,
doesn't
it?
The component doesn't need to register an image with a
service,
it
can register the service that creates the images.
The images themselves can be created on the
first request
http://www..../app?service=mydynamicbuttons&button=A
Whenever this url is hit wicket forwards the
control to
the registered mydynamicbuttons service (registered
by whatever
component) which creates the image A, caches it, and
streams
it
to
response. Or precreate whatever you need when
the service
object is
created and registered with the application.
And THIS last part is just the problem
how does it register itself? When?
Where is it specified that a component does that?
I think in the end we have exactly the same thing...
you have a file like:
mydynamicbuttons=my.class.that.exposes.this.Service
johan
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software
Conference &
EXPO
September 19-22, 2005 * San Francisco, CA * Development
Lifecycle
Practices Agile & Plan-Driven Development * Managing
Projects & Teams
* Testing & QA Security * Process Improvement &
Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develo
p
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software
Conference
&
EXPO
September 19-22, 2005 * San Francisco, CA * Development
Lifecycle
Practices Agile & Plan-Driven Development * Managing
Projects &
Teams
* Testing & QA Security * Process Improvement &
Measurement
* http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software
Conference
&
EXPO
September 19-22, 2005 * San Francisco, CA * Development
Lifecycle Practices Agile & Plan-Driven Development *
Managing Projects & Teams *
Testing
& QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software
Conference &
EXPO September 19-22, 2005 * San Francisco, CA *
Development
Lifecycle
Practices
Agile & Plan-Driven Development * Managing
Projects & Teams *
Testing
&
QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
--
http://www.desktopbeautifier.com/
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software
Conference &
EXPO September 19-22, 2005 * San Francisco, CA *
Development
Lifecycle Practices Agile & Plan-Driven Development
* Managing
Projects & Teams *
Testing
&
QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software
Conference &
EXPO September 19-22, 2005 * San Francisco, CA *
Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams *
Testing &
QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
--
http://www.desktopbeautifier.com/
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference
& EXPO September 19-22, 2005 * San Francisco, CA *
Development Lifecycle Practices Agile & Plan-Driven
Development *
Managing
Projects & Teams * Testing
&
QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference
& EXPO September 19-22, 2005 * San Francisco, CA *
Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams
* Testing
&
QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
--
http://www.desktopbeautifier.com/
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software
Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development
Lifecycle
Practices Agile & Plan-Driven Development * Managing Projects
& Teams * Testing &
QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software
Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams *
Testing &
QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software
Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development
Lifecycle Practices Agile & Plan-Driven Development * Managing
Projects & Teams * Testing & QA Security * Process Improvement
&
Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference &
EXPO September 19-22, 2005 * San Francisco, CA * Development
Lifecycle Practices Agile & Plan-Driven Development *
Managing
Projects & Teams
* Testing & QA Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference &
EXPO September 19-22, 2005 * San Francisco, CA * Development
Lifecycle Practices Agile & Plan-Driven Development * Managing
Projects & Teams
* Testing & QA Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices Agile & Plan-Driven Development * Managing Projects &
Teams * Testing & QA Security * Process Improvement & Measurement
* http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams *
Testing & QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams *
Testing & QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
