I've confused myself... Object factory plugin?
28 views
Skip to first unread message
Scott
Jan 4, 2012, 2:38:30 PM1/4/12
to jspf
Ok, I'm sure this is due to a lack of sleep and/or coffee, but I can't
seem to figure out the "right" way to set this up in my project...
I have a "SqlPlugin" that provides an embedded HSQLDB server. It
creates a connection pool and provides a "getSql" method that returns
a new instance of "Sql" to the calling program that can then be used
to query the database.
Where does the "Sql" class go? If I put it in the plugin project, is
it really in the plugin or is it just working because it happens to be
in the classpath with the main program? (I vote for the second
option.)
How do I add this second object and still keep things loosely-
coupled? How do I keep the implementation part of the whole SQL
plugin yet still be able to instantiate a bunch of them?
Thanks. So far, I'm really liking this framework!
Scott
seem to figure out the "right" way to set this up in my project...
I have a "SqlPlugin" that provides an embedded HSQLDB server. It
creates a connection pool and provides a "getSql" method that returns
a new instance of "Sql" to the calling program that can then be used
to query the database.
Where does the "Sql" class go? If I put it in the plugin project, is
it really in the plugin or is it just working because it happens to be
in the classpath with the main program? (I vote for the second
option.)
How do I add this second object and still keep things loosely-
coupled? How do I keep the implementation part of the whole SQL
plugin yet still be able to instantiate a bunch of them?
Thanks. So far, I'm really liking this framework!
Scott
Ralf
Jan 4, 2012, 2:47:50 PM1/4/12
to jspf
On 4 Jan., 11:38, Scott <scott.duens...@gmail.com> wrote:
> Ok, I'm sure this is due to a lack of sleep and/or coffee, but I can't
> seem to figure out the "right" way to set this up in my project...
> I have a "SqlPlugin" that provides an embedded HSQLDB server. It
> creates a connection pool and provides a "getSql" method that returns
> a new instance of "Sql" to the calling program that can then be used
> to query the database.
> Where does the "Sql" class go? If I put it in the plugin project, is
> it really in the plugin or is it just working because it happens to be
> in the classpath with the main program? (I vote for the second
> option.)
implementation you would put it into the main project and ship it
there, then JSPF should find it when resolving the plugin and the
plugin JAR would not need to provide it.
In fact, you should not - and can not - put it solely into a plugin
JAR when you want to access it from somewhere else, since the class
will then be unknown. Only when being used internally you would bundle
it with the plugin JAR.
In your case you'd probably want to put Sql into the main application.
The individual plugins can then ship without it.
> How do I add this second object and still keep things loosely-
> coupled? How do I keep the implementation part of the whole SQL
> plugin yet still be able to instantiate a bunch of them?
Cheers
Ralf
Scott
Jan 4, 2012, 2:56:50 PM1/4/12
to jspf
Holy crap that was a fast answer! :-)
On Jan 4, 1:47 pm, Ralf <r.bied...@googlemail.com> wrote:
> In fact, you should not - and can not - put it solely into a plugin
> JAR when you want to access it from somewhere else, since the class
> will then be unknown. Only when being used internally you would bundle
> it with the plugin JAR.
>
although unlikely - different "SqlPlugins" may need different
implementations of "Sql". I can define an interface for "Sql" that
the rest of the world can know about, but how do I then deliver the
object itself at runtime? Make it another plugin? (Except I read
elsewhere that you can't instantiate a plugin more than once.)
Scott
On Jan 4, 1:47 pm, Ralf <r.bied...@googlemail.com> wrote:
> In fact, you should not - and can not - put it solely into a plugin
> JAR when you want to access it from somewhere else, since the class
> will then be unknown. Only when being used internally you would bundle
> it with the plugin JAR.
>
> > How do I add this second object and still keep things loosely-
> > coupled? How do I keep the implementation part of the whole SQL
> > plugin yet still be able to instantiate a bunch of them?
>
> I don't get that part ...
The reason I don't want to include it with the main program is that -
> > coupled? How do I keep the implementation part of the whole SQL
> > plugin yet still be able to instantiate a bunch of them?
>
> I don't get that part ...
although unlikely - different "SqlPlugins" may need different
implementations of "Sql". I can define an interface for "Sql" that
the rest of the world can know about, but how do I then deliver the
object itself at runtime? Make it another plugin? (Except I read
elsewhere that you can't instantiate a plugin more than once.)
Scott
Ralf
Jan 4, 2012, 3:29:16 PM1/4/12
to jspf
JSPF = Java Support Politely & Fast ... although I have plans to ditch
the P :)
> On Jan 4, 1:47 pm, Ralf <r.bied...@googlemail.com> wrote:
> > > How do I add this second object and still keep things loosely-
> > > coupled? How do I keep the implementation part of the whole SQL
> > > plugin yet still be able to instantiate a bunch of them?
you can either:
1) Bundle Sql with the main app. In that case everyone can use it, but
is strongly coupled to it.
2) Bundle various Sqls with (each of) the plugins. Plugins remain
independent but you need to "copy" code.
3) Provide a (set of) dedicated Sql provider plugin(s). However this
is almost similar to 1)
Best solution depends on a number of factors. For example, how likely
is it that you Sql class needs to be replaced / bug fixed? Frankly I
don't know if there is a best way to solve it, and I used all three
variants in various projects. You could try to ship a robust BaseSQL
or something with 1) which does 90% of the job and who needs it can
extend it. Same could be done with 3). Alternatively, if your build
system is automated enough, 2) is probably a solid solution. In that
case you could automatically enclose an Sql instance when you pack a
plugin.
Let me know if you find a silver bullet.
Cheers,
Ralf
the P :)
> On Jan 4, 1:47 pm, Ralf <r.bied...@googlemail.com> wrote:
> > > How do I add this second object and still keep things loosely-
> > > coupled? How do I keep the implementation part of the whole SQL
> > > plugin yet still be able to instantiate a bunch of them?
> The reason I don't want to include it with the main program is that -
> although unlikely - different "SqlPlugins" may need different
> implementations of "Sql". I can define an interface for "Sql" that
> the rest of the world can know about, but how do I then deliver the
> object itself at runtime? Make it another plugin? (Except I read
> elsewhere that you can't instantiate a plugin more than once.)
Ah, you mean Sql is a class, not an interface. Well, yes, in that case
> although unlikely - different "SqlPlugins" may need different
> implementations of "Sql". I can define an interface for "Sql" that
> the rest of the world can know about, but how do I then deliver the
> object itself at runtime? Make it another plugin? (Except I read
> elsewhere that you can't instantiate a plugin more than once.)
you can either:
1) Bundle Sql with the main app. In that case everyone can use it, but
is strongly coupled to it.
2) Bundle various Sqls with (each of) the plugins. Plugins remain
independent but you need to "copy" code.
3) Provide a (set of) dedicated Sql provider plugin(s). However this
is almost similar to 1)
Best solution depends on a number of factors. For example, how likely
is it that you Sql class needs to be replaced / bug fixed? Frankly I
don't know if there is a best way to solve it, and I used all three
variants in various projects. You could try to ship a robust BaseSQL
or something with 1) which does 90% of the job and who needs it can
extend it. Same could be done with 3). Alternatively, if your build
system is automated enough, 2) is probably a solid solution. In that
case you could automatically enclose an Sql instance when you pack a
plugin.
Let me know if you find a silver bullet.
Cheers,
Ralf
Scott
Jan 4, 2012, 4:00:29 PM1/4/12
to jspf
On Jan 4, 2:29 pm, Ralf <r.bied...@googlemail.com> wrote:
> JSPF = Java Support Politely & Fast ... although I have plans to ditch
> the P :)
stay as good as they are now!
> Let me know if you find a silver bullet.
ship it with the base application. If I have a brain fart, I'll be
sure to follow up.
Thanks again!
Scott
Reply all
Reply to author
Forward
0 new messages