You are viewing a plain text version of this content. The canonical link for it is here.
Posted to muse-user@ws.apache.org by Balan Subramanian <bs...@us.ibm.com> on 2007/01/03 16:55:02 UTC
Different packaging for OSGi based endpoints
The OSGi bundling of WSDM endpoints is gaining a lot of popularity
particularly with the possibility of J2ME being supported officially in
2.2.
If I understand correctly, each endpoint deployed in an OSGi container
will drag along with it, its own set of Muse JAR files and will also load
them separately per endpoint. This is a huge concern for some deployers
given the additional footprint both on disk and memory. Also it seems
contrary to OSGi design principles to have multiple instances of the same
bundles running.
Please correct me if I am wrong - it would be great if this issue has
already been addressed. However if not, is this something that can be
addressed in 2.2?
Balan Subramanian
Autonomic Computing, IBM, RTP, NC
919.543.0197 | bsubram@us.ibm.com
Re: Different packaging for OSGi based endpoints
Posted by Balan Subramanian <bs...@us.ibm.com>.
Joel, can you please confirm?
Balan Subramanian
Autonomic Computing, IBM, RTP, NC
919.543.0197 | bsubram@us.ibm.com
Daniel Jemiolo/Durham/IBM@IBMUS
01/03/2007 11:48 AM
Please respond to
muse-user@ws.apache.org
To
muse-user@ws.apache.org
cc
Subject
Re: Different packaging for OSGi based endpoints
Joel is the authority here, so I will defer to him, but I believe the
reason that all Muse JARs are packaged as OSGi bundles is to fit into the
OSGi deployment model. One copy of the bundles (each representing one Muse
JAR, except in the case of muse-util-all, which has all the utility JARs)
for each Equinox deployment. The confusion may be that when wsdl2java
generates an OSGi project, it copies over all of the Equinox/Muse JARs
into the new project, in addition to the user's new code and XML files; if
you generate a new project, it will do so again, rather than adding the
new resource type files to the same Equinox installation.
But again, I'd like to hear from Joel.
Dan
Balan Subramanian/Raleigh/IBM@IBMUS wrote on 01/03/2007 10:55:02 AM:
> The OSGi bundling of WSDM endpoints is gaining a lot of popularity
> particularly with the possibility of J2ME being supported officially in
> 2.2.
>
> If I understand correctly, each endpoint deployed in an OSGi container
> will drag along with it, its own set of Muse JAR files and will also
load
> them separately per endpoint. This is a huge concern for some deployers
> given the additional footprint both on disk and memory. Also it seems
> contrary to OSGi design principles to have multiple instances of the
same
> bundles running.
>
> Please correct me if I am wrong - it would be great if this issue has
> already been addressed. However if not, is this something that can be
> addressed in 2.2?
>
> Balan Subramanian
> Autonomic Computing, IBM, RTP, NC
> 919.543.0197 | bsubram@us.ibm.com
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
Re: Different packaging for OSGi based endpoints
Posted by Daniel Jemiolo <da...@us.ibm.com>.
I think adding our jars to a server's endorsed libraries is a big
configuration change that should not be done without user interaction; in
other words, if the user wants to trim things down and move Muse jars to
the endorsed directory, he should just do that. It's not a complicated or
tedious task. Anything that affects the classpath shouldn't be done
lightly, especially in J2EE where the classloading is more complicated
than in a simple Java app.
So - I agree I would probably do this if I had multiple WAR files using
Muse (and I couldn't consolidate my endpoints into one WAR, for whatever
reason). However, I think it's an optimization we should leave to the
user.
Dan
Balan Subramanian/Raleigh/IBM@IBMUS wrote on 01/05/2007 05:36:15 PM:
> So the solution may be to provide a flag in code gen about whether to
add
> the jars or not into the generated project.
>
> Also, I think this is a problem as well when deploying on J2EE. It would
> be better if common JARs (muse) can be placed in the common/shared
folder
> of the app server (almost all of them have one).
>
> Balan Subramanian
> Autonomic Computing, IBM, RTP, NC
> 919.543.0197 | bsubram@us.ibm.com
>
>
>
>
>
>
> Daniel Jemiolo/Durham/IBM@IBMUS
> 01/03/2007 11:48 AM
> Please respond to
> muse-user@ws.apache.org
>
>
> To
> muse-user@ws.apache.org
> cc
>
> Subject
> Re: Different packaging for OSGi based endpoints
>
>
>
>
>
>
> Joel is the authority here, so I will defer to him, but I believe the
> reason that all Muse JARs are packaged as OSGi bundles is to fit into
the
> OSGi deployment model. One copy of the bundles (each representing one
Muse
>
> JAR, except in the case of muse-util-all, which has all the utility
JARs)
> for each Equinox deployment. The confusion may be that when wsdl2java
> generates an OSGi project, it copies over all of the Equinox/Muse JARs
> into the new project, in addition to the user's new code and XML files;
if
>
> you generate a new project, it will do so again, rather than adding the
> new resource type files to the same Equinox installation.
>
> But again, I'd like to hear from Joel.
>
> Dan
>
>
>
> Balan Subramanian/Raleigh/IBM@IBMUS wrote on 01/03/2007 10:55:02 AM:
>
> > The OSGi bundling of WSDM endpoints is gaining a lot of popularity
> > particularly with the possibility of J2ME being supported officially
in
> > 2.2.
> >
> > If I understand correctly, each endpoint deployed in an OSGi container
> > will drag along with it, its own set of Muse JAR files and will also
> load
> > them separately per endpoint. This is a huge concern for some
deployers
> > given the additional footprint both on disk and memory. Also it seems
> > contrary to OSGi design principles to have multiple instances of the
> same
> > bundles running.
> >
> > Please correct me if I am wrong - it would be great if this issue has
> > already been addressed. However if not, is this something that can be
> > addressed in 2.2?
> >
> > Balan Subramanian
> > Autonomic Computing, IBM, RTP, NC
> > 919.543.0197 | bsubram@us.ibm.com
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
Re: Different packaging for OSGi based endpoints
Posted by Balan Subramanian <bs...@us.ibm.com>.
So the solution may be to provide a flag in code gen about whether to add
the jars or not into the generated project.
Also, I think this is a problem as well when deploying on J2EE. It would
be better if common JARs (muse) can be placed in the common/shared folder
of the app server (almost all of them have one).
Balan Subramanian
Autonomic Computing, IBM, RTP, NC
919.543.0197 | bsubram@us.ibm.com
Daniel Jemiolo/Durham/IBM@IBMUS
01/03/2007 11:48 AM
Please respond to
muse-user@ws.apache.org
To
muse-user@ws.apache.org
cc
Subject
Re: Different packaging for OSGi based endpoints
Joel is the authority here, so I will defer to him, but I believe the
reason that all Muse JARs are packaged as OSGi bundles is to fit into the
OSGi deployment model. One copy of the bundles (each representing one Muse
JAR, except in the case of muse-util-all, which has all the utility JARs)
for each Equinox deployment. The confusion may be that when wsdl2java
generates an OSGi project, it copies over all of the Equinox/Muse JARs
into the new project, in addition to the user's new code and XML files; if
you generate a new project, it will do so again, rather than adding the
new resource type files to the same Equinox installation.
But again, I'd like to hear from Joel.
Dan
Balan Subramanian/Raleigh/IBM@IBMUS wrote on 01/03/2007 10:55:02 AM:
> The OSGi bundling of WSDM endpoints is gaining a lot of popularity
> particularly with the possibility of J2ME being supported officially in
> 2.2.
>
> If I understand correctly, each endpoint deployed in an OSGi container
> will drag along with it, its own set of Muse JAR files and will also
load
> them separately per endpoint. This is a huge concern for some deployers
> given the additional footprint both on disk and memory. Also it seems
> contrary to OSGi design principles to have multiple instances of the
same
> bundles running.
>
> Please correct me if I am wrong - it would be great if this issue has
> already been addressed. However if not, is this something that can be
> addressed in 2.2?
>
> Balan Subramanian
> Autonomic Computing, IBM, RTP, NC
> 919.543.0197 | bsubram@us.ibm.com
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
Re: Different packaging for OSGi based endpoints
Posted by Daniel Jemiolo <da...@us.ibm.com>.
Joel is the authority here, so I will defer to him, but I believe the
reason that all Muse JARs are packaged as OSGi bundles is to fit into the
OSGi deployment model. One copy of the bundles (each representing one Muse
JAR, except in the case of muse-util-all, which has all the utility JARs)
for each Equinox deployment. The confusion may be that when wsdl2java
generates an OSGi project, it copies over all of the Equinox/Muse JARs
into the new project, in addition to the user's new code and XML files; if
you generate a new project, it will do so again, rather than adding the
new resource type files to the same Equinox installation.
But again, I'd like to hear from Joel.
Dan
Balan Subramanian/Raleigh/IBM@IBMUS wrote on 01/03/2007 10:55:02 AM:
> The OSGi bundling of WSDM endpoints is gaining a lot of popularity
> particularly with the possibility of J2ME being supported officially in
> 2.2.
>
> If I understand correctly, each endpoint deployed in an OSGi container
> will drag along with it, its own set of Muse JAR files and will also
load
> them separately per endpoint. This is a huge concern for some deployers
> given the additional footprint both on disk and memory. Also it seems
> contrary to OSGi design principles to have multiple instances of the
same
> bundles running.
>
> Please correct me if I am wrong - it would be great if this issue has
> already been addressed. However if not, is this something that can be
> addressed in 2.2?
>
> Balan Subramanian
> Autonomic Computing, IBM, RTP, NC
> 919.543.0197 | bsubram@us.ibm.com
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org