You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jarek Gawor <jg...@gmail.com> on 2010/01/24 03:55:48 UTC

rfc66 update

Hi all,

Today I checked in an initial version of the rfc66 extender that can
actually deploy WABs with simple servlets and jsps. There is still
much work to be done (for example updating the Jasper module builder
to work with Bundles) but simple stuff seems to be working. In fact
with David's recent JNDI (rfc142) integration work I was able to
deploy the Aries blog sample in Geronimo.

Here are the steps I took to run the sample:

1) Build latest blog sample in Aries
2) Build latest Geronimo trunk
3) cd plugins/wab/web-tomcat-server/target/assembly (or
web-jetty-server if you prefer)
4) Create database for blog sample using blogDB.sql from blog sample:

java -cp repository/org/apache/geronimo/bundles/derby-all/10.4.2.0-SNAPSHOT/derby-all-10.4.2.0-SNAPSHOT.jar
org.apache.derby.tools.ij
<aries>/samples/blog-sample/blog-assembly/target/blogDB.sql

5) Move created blogDB directory to
plugins/wab/web-tomcat-server/target/assembly/var/derby

6) Start server:

./bin/geronimo -l

7) Install and start all the blog sample bundles (blog-api-1.0.0.jar,
blog-persistence-1.0.0.jar, blog-1.0.0.jar, blog-servlet-1.0.0.jar)
using the karaf console.

8) Once you start the blog-servlet-1.0.0.jar bundle, the WAB will be
deployed and you should be able to access http://localhost:8080/blog.
And if everything is running right you should be able to add new blog
entries, etc.

Enjoy,
Jarek

Re: rfc66 update

Posted by Jarek Gawor <jg...@gmail.com>.
On Thu, Jan 28, 2010 at 5:36 AM, Delos <da...@gmail.com> wrote:
> For the handler improvement, I think WarConverterService returning
> InputStream is more common for user to use. If we need, we can make use of
> it and write the bytes from inputStream into  a file in Geronimo. What's
> your opinion?

I think you misunderstood. The InputStream returned by
WarToWabConverterImpl.getWAB() is backed by byte array. We still want
to return an InputStream but backed by a file.

> For the importing bug, is it
> https://issues.apache.org/jira/browse/ARIES-15?  I'm looking into it.

Yes. There was some discussions about this issue on the Aries mailing
list a while ago that you might find useful.

Jarek

Re: rfc66 update

Posted by Delos <da...@gmail.com>.
For the handler improvement, I think WarConverterService returning
InputStream is more common for user to use. If we need, we can make use of
it and write the bytes from inputStream into  a file in Geronimo. What's
your opinion?

For the importing bug, is it https://issues.apache.org/jira/browse/ARIES-15?
I'm looking into it.


2010/1/28 Delos <da...@gmail.com>

> Jarek,
>
> I agree with you that the handler is ready once we start it.
>
> But, IMO, to make use of the URL handler, we may have other work to do.
> According to RFC 66 , at least we need to generate a URL to make the handler
> invoked.  The URL has to follow the URL schema definition in RFC 66. Some
> additional information maybe provided such Bundle-SymbolicName,
> Bundle-Version, etc. First, I think we have to define the default values of
> these headers  for a WAR in G3.0.
>
> The URL generation work may not be included in Web extender, but I think
> it's Web extender related.
>
> What's your opinion?
>
>
> 2010/1/28 Jarek Gawor <jg...@gmail.com>
>
> Delos,
>>
>> Comments in-lined:
>>
>> On Wed, Jan 27, 2010 at 6:33 AM, Delos <da...@gmail.com> wrote:
>> > Hi Jarek,
>> >
>> > I see what you meant. The tracker will only add WAB once. Sorry for my
>> > misunderstanding.
>> >
>> > I found several items in TODO file. Besides, I think we may also take
>> these
>> > two items. If possible, I hope to take them.
>> > 1) I note you have added URLHandler package from Aries as a dependency.
>> Is
>> > there any plan how to make use of it to convert WAR into WAB? I'd like
>> to
>> > take it.
>>
>> It's already being used. The handler is configured via Blueprint so as
>> soon as the handler bundle is started everything is setup right. So
>> there is nothing to do from Geronimo side for the handler. We just
>> need to start it. However, there are a few things that can be improved
>> in the handler code itself. For example, I think right now when it
>> creates the bundle it, it keeps the entire content of the bundle in
>> memory as a byte array. We could improve it so that it writes the
>> bundle data to a file instead. Also, there is a bug open on how the
>> handler generates the Import-Package imports.
>>
>> > 2) For the lazy activate WAB, I'm not sure if it's an optional feature.
>> > Anyway, I hope to get a workaround for it. I will raise a discussion
>> once I
>> > find any.
>>
>> I'm pretty sure it's an optional feature :). And from my initial
>> analysis while looking at the whole rfc66 stuff it seemed it would be
>> pretty difficult to get Geronimo working with lazy bundles as
>> described in the spec. So at the end I decided not to worry about
>> it... unless there is a clear indication that this feature must be
>> supported.
>>
>> Jarek
>>
>
>
>
> --
> Best Regards,
>
> Delos
>



-- 
Best Regards,

Delos

Re: rfc66 update

Posted by Delos <da...@gmail.com>.
OK. I got it. I'm curious about the scenario when user can deploy a WAR with
BundleContext.installBundle()? Is it included in the programming model of
Aries?

Thanks!

2010/1/29 Jarek Gawor <jg...@gmail.com>

> Delos,
>
> I'm not sure I understand what you are saying. Nothing in Geronimo
> needs to generate this webbundle url. It's the user that will have to
> construct the right url to deploy a war file using the osgi api
> (BundleContext.installBundle()).
> If the user is deploying a war file using the deployer tool (using
> jsr88 api) that will NOT invoke the webbundle url handler or use the
> rfc66 extender. At least that's how things work right now and so in
> effect we have two different ways of converting a war into a bundle.
> Maybe that's the point of confusion?
> The url handler in Aries already has some defaults for
> Bundle-SymbolicName, etc. I don't think these defaults can be
> configured and maybe that's something to improve in Aries but I think
> they are ok for now.
>
> Jarek
>
> On Thu, Jan 28, 2010 at 2:35 AM, Delos <da...@gmail.com> wrote:
> > Jarek,
> >
> > I agree with you that the handler is ready once we start it.
> >
> > But, IMO, to make use of the URL handler, we may have other work to do.
> > According to RFC 66 , at least we need to generate a URL to make the
> handler
> > invoked.  The URL has to follow the URL schema definition in RFC 66. Some
> > additional information maybe provided such Bundle-SymbolicName,
> > Bundle-Version, etc. First, I think we have to define the default values
> of
> > these headers  for a WAR in G3.0.
> >
> > The URL generation work may not be included in Web extender, but I think
> > it's Web extender related.
> >
> > What's your opinion?
> >
> >
> > 2010/1/28 Jarek Gawor <jg...@gmail.com>
> >>
> >> Delos,
> >>
> >> Comments in-lined:
> >>
> >> On Wed, Jan 27, 2010 at 6:33 AM, Delos <da...@gmail.com> wrote:
> >> > Hi Jarek,
> >> >
> >> > I see what you meant. The tracker will only add WAB once. Sorry for my
> >> > misunderstanding.
> >> >
> >> > I found several items in TODO file. Besides, I think we may also take
> >> > these
> >> > two items. If possible, I hope to take them.
> >> > 1) I note you have added URLHandler package from Aries as a
> dependency.
> >> > Is
> >> > there any plan how to make use of it to convert WAR into WAB? I'd like
> >> > to
> >> > take it.
> >>
> >> It's already being used. The handler is configured via Blueprint so as
> >> soon as the handler bundle is started everything is setup right. So
> >> there is nothing to do from Geronimo side for the handler. We just
> >> need to start it. However, there are a few things that can be improved
> >> in the handler code itself. For example, I think right now when it
> >> creates the bundle it, it keeps the entire content of the bundle in
> >> memory as a byte array. We could improve it so that it writes the
> >> bundle data to a file instead. Also, there is a bug open on how the
> >> handler generates the Import-Package imports.
> >>
> >> > 2) For the lazy activate WAB, I'm not sure if it's an optional
> feature.
> >> > Anyway, I hope to get a workaround for it. I will raise a discussion
> >> > once I
> >> > find any.
> >>
> >> I'm pretty sure it's an optional feature :). And from my initial
> >> analysis while looking at the whole rfc66 stuff it seemed it would be
> >> pretty difficult to get Geronimo working with lazy bundles as
> >> described in the spec. So at the end I decided not to worry about
> >> it... unless there is a clear indication that this feature must be
> >> supported.
> >>
> >> Jarek
> >
> >
> >
> > --
> > Best Regards,
> >
> > Delos
> >
>



-- 
Best Regards,

Delos

Re: rfc66 update

Posted by Jarek Gawor <jg...@gmail.com>.
Delos,

I'm not sure I understand what you are saying. Nothing in Geronimo
needs to generate this webbundle url. It's the user that will have to
construct the right url to deploy a war file using the osgi api
(BundleContext.installBundle()).
If the user is deploying a war file using the deployer tool (using
jsr88 api) that will NOT invoke the webbundle url handler or use the
rfc66 extender. At least that's how things work right now and so in
effect we have two different ways of converting a war into a bundle.
Maybe that's the point of confusion?
The url handler in Aries already has some defaults for
Bundle-SymbolicName, etc. I don't think these defaults can be
configured and maybe that's something to improve in Aries but I think
they are ok for now.

Jarek

On Thu, Jan 28, 2010 at 2:35 AM, Delos <da...@gmail.com> wrote:
> Jarek,
>
> I agree with you that the handler is ready once we start it.
>
> But, IMO, to make use of the URL handler, we may have other work to do.
> According to RFC 66 , at least we need to generate a URL to make the handler
> invoked.  The URL has to follow the URL schema definition in RFC 66. Some
> additional information maybe provided such Bundle-SymbolicName,
> Bundle-Version, etc. First, I think we have to define the default values of
> these headers  for a WAR in G3.0.
>
> The URL generation work may not be included in Web extender, but I think
> it's Web extender related.
>
> What's your opinion?
>
>
> 2010/1/28 Jarek Gawor <jg...@gmail.com>
>>
>> Delos,
>>
>> Comments in-lined:
>>
>> On Wed, Jan 27, 2010 at 6:33 AM, Delos <da...@gmail.com> wrote:
>> > Hi Jarek,
>> >
>> > I see what you meant. The tracker will only add WAB once. Sorry for my
>> > misunderstanding.
>> >
>> > I found several items in TODO file. Besides, I think we may also take
>> > these
>> > two items. If possible, I hope to take them.
>> > 1) I note you have added URLHandler package from Aries as a dependency.
>> > Is
>> > there any plan how to make use of it to convert WAR into WAB? I'd like
>> > to
>> > take it.
>>
>> It's already being used. The handler is configured via Blueprint so as
>> soon as the handler bundle is started everything is setup right. So
>> there is nothing to do from Geronimo side for the handler. We just
>> need to start it. However, there are a few things that can be improved
>> in the handler code itself. For example, I think right now when it
>> creates the bundle it, it keeps the entire content of the bundle in
>> memory as a byte array. We could improve it so that it writes the
>> bundle data to a file instead. Also, there is a bug open on how the
>> handler generates the Import-Package imports.
>>
>> > 2) For the lazy activate WAB, I'm not sure if it's an optional feature.
>> > Anyway, I hope to get a workaround for it. I will raise a discussion
>> > once I
>> > find any.
>>
>> I'm pretty sure it's an optional feature :). And from my initial
>> analysis while looking at the whole rfc66 stuff it seemed it would be
>> pretty difficult to get Geronimo working with lazy bundles as
>> described in the spec. So at the end I decided not to worry about
>> it... unless there is a clear indication that this feature must be
>> supported.
>>
>> Jarek
>
>
>
> --
> Best Regards,
>
> Delos
>

Re: rfc66 update

Posted by Delos <da...@gmail.com>.
Jarek,

I agree with you that the handler is ready once we start it.

But, IMO, to make use of the URL handler, we may have other work to do.
According to RFC 66 , at least we need to generate a URL to make the handler
invoked.  The URL has to follow the URL schema definition in RFC 66. Some
additional information maybe provided such Bundle-SymbolicName,
Bundle-Version, etc. First, I think we have to define the default values of
these headers  for a WAR in G3.0.

The URL generation work may not be included in Web extender, but I think
it's Web extender related.

What's your opinion?


2010/1/28 Jarek Gawor <jg...@gmail.com>

> Delos,
>
> Comments in-lined:
>
> On Wed, Jan 27, 2010 at 6:33 AM, Delos <da...@gmail.com> wrote:
> > Hi Jarek,
> >
> > I see what you meant. The tracker will only add WAB once. Sorry for my
> > misunderstanding.
> >
> > I found several items in TODO file. Besides, I think we may also take
> these
> > two items. If possible, I hope to take them.
> > 1) I note you have added URLHandler package from Aries as a dependency.
> Is
> > there any plan how to make use of it to convert WAR into WAB? I'd like to
> > take it.
>
> It's already being used. The handler is configured via Blueprint so as
> soon as the handler bundle is started everything is setup right. So
> there is nothing to do from Geronimo side for the handler. We just
> need to start it. However, there are a few things that can be improved
> in the handler code itself. For example, I think right now when it
> creates the bundle it, it keeps the entire content of the bundle in
> memory as a byte array. We could improve it so that it writes the
> bundle data to a file instead. Also, there is a bug open on how the
> handler generates the Import-Package imports.
>
> > 2) For the lazy activate WAB, I'm not sure if it's an optional feature.
> > Anyway, I hope to get a workaround for it. I will raise a discussion once
> I
> > find any.
>
> I'm pretty sure it's an optional feature :). And from my initial
> analysis while looking at the whole rfc66 stuff it seemed it would be
> pretty difficult to get Geronimo working with lazy bundles as
> described in the spec. So at the end I decided not to worry about
> it... unless there is a clear indication that this feature must be
> supported.
>
> Jarek
>



-- 
Best Regards,

Delos

Re: rfc66 update

Posted by Jarek Gawor <jg...@gmail.com>.
Delos,

Comments in-lined:

On Wed, Jan 27, 2010 at 6:33 AM, Delos <da...@gmail.com> wrote:
> Hi Jarek,
>
> I see what you meant. The tracker will only add WAB once. Sorry for my
> misunderstanding.
>
> I found several items in TODO file. Besides, I think we may also take these
> two items. If possible, I hope to take them.
> 1) I note you have added URLHandler package from Aries as a dependency. Is
> there any plan how to make use of it to convert WAR into WAB? I'd like to
> take it.

It's already being used. The handler is configured via Blueprint so as
soon as the handler bundle is started everything is setup right. So
there is nothing to do from Geronimo side for the handler. We just
need to start it. However, there are a few things that can be improved
in the handler code itself. For example, I think right now when it
creates the bundle it, it keeps the entire content of the bundle in
memory as a byte array. We could improve it so that it writes the
bundle data to a file instead. Also, there is a bug open on how the
handler generates the Import-Package imports.

> 2) For the lazy activate WAB, I'm not sure if it's an optional feature.
> Anyway, I hope to get a workaround for it. I will raise a discussion once I
> find any.

I'm pretty sure it's an optional feature :). And from my initial
analysis while looking at the whole rfc66 stuff it seemed it would be
pretty difficult to get Geronimo working with lazy bundles as
described in the spec. So at the end I decided not to worry about
it... unless there is a clear indication that this feature must be
supported.

Jarek

Re: rfc66 update

Posted by Delos <da...@gmail.com>.
Hi Jarek,

I see what you meant. The tracker will only add WAB once. Sorry for my
misunderstanding.

I found several items in TODO file. Besides, I think we may also take these
two items. If possible, I hope to take them.
1) I note you have added URLHandler package from Aries as a dependency. Is
there any plan how to make use of it to convert WAR into WAB? I'd like to
take it.

2) For the lazy activate WAB, I'm not sure if it's an optional feature.
Anyway, I hope to get a workaround for it. I will raise a discussion once I
find any.

Any comments?

Thanks a lot!

2010/1/27 Jarek Gawor <jg...@gmail.com>

> Delos,
>
> Why do you think a lazy bundle will be deployed twice? I did not test
> the code with lazy bundles so It's possible I missed something but I
> think the code is right. Once lazy activated WAB is detected, it will
> be tracked by the BundleTracker (by returning non-null value in
> addingBundle()). And if the state of such tracked bundle changes from
> STARTING to ACTIVE, the modifiedBundle() will be called and not
> addingBundle(). addingBundle() will be called twice on a lazy bundle
> that is not a WAB but such bundle will be safely ignored.
>
> Jarek
>
> On Tue, Jan 26, 2010 at 4:39 AM, Delos <da...@gmail.com> wrote:
> > Thanks for your reply!
> >
> > I still have a concern about lazy activated bundle in current
> > implementation. In BundleTrackerCustomizer, a lazy activated bundle will
> be
> > deployed twice(deployed->undeployed->deployed), because of the state
> > transition of the bundle. To avoid this, I suggest to create a separated
> > BundleTracker and BundleTrackerCustomizer for lazy-activated Starting
> > bundles. Then original BundleTrackerCustomizer can only deploy and
> undeploy
> > Active bundle, while the new BundleTrackerCustomizer only deploys the
> > lazy-activated Starting bundles.
> >
> > Any comments?
> >
> > 2010/1/25 Rick McGuire <ri...@gmail.com>
> >>
> >> On 1/25/2010 8:06 AM, Delos wrote:
> >>
> >> It's really great news!
> >>
> >> But I have some questions about current implementation.Just want to
> learn
> >> more from it.
> >>
> >> 1) I found only active and starting bundles are taken into account in
> >> current implementation. What about resolved bundles?
> >>
> >> That's the requirement of the RFC66 specification.  Resolution is a
> >> requirement for a bundle to transition to the active or starting states,
> but
> >> the extender is not supposed to take action until one of those states is
> >> seen.  It's the same way with Blueprint.
> >>
> >>
> >> 2) For lazy activiated bundles, only starting bundles will be
> deployed.But
> >> in RFC 66, it said "A bundle that has a lazy activation policy should
> not be
> >> transitioned to the STARTING state by the web extender unless a request
> is
> >> made that requires a class to be loaded." Does the implementation
> violate
> >> the document?
> >>
> >> This is a statement that the extender should not explicitly force the
> >> bundle into a started state, but rather should leave that transition to
> one
> >> triggered by a class load.  If the processing the extender needs to
> perform
> >> in processing the bundle results in a triggering class load, that's ok.
> >>
> >>
> >> 3) In RFC 66, static content can be requested without starting a WAB.
> It's
> >> not in the TODO file. Do you have any idea for it? I'm not sure if
> >> configuration of WAB can become accessible before actually it's started.
> >>
> >> The note about static content is marked as an optional feature.  For a
> lot
> >> of processing, it would not be possible to achieve deployment without
> >> performing a classload.
> >>
> >>
> >> Thanks!
> >>
> >> 2010/1/24 David Jencks <da...@yahoo.com>
> >>>
> >>> great news! congratulations!
> >>>
> >>> david jencks
> >>>
> >>> On Jan 23, 2010, at 6:55 PM, Jarek Gawor wrote:
> >>>
> >>>> Hi all,
> >>>>
> >>>> Today I checked in an initial version of the rfc66 extender that can
> >>>> actually deploy WABs with simple servlets and jsps. There is still
> >>>> much work to be done (for example updating the Jasper module builder
> >>>> to work with Bundles) but simple stuff seems to be working. In fact
> >>>> with David's recent JNDI (rfc142) integration work I was able to
> >>>> deploy the Aries blog sample in Geronimo.
> >>>>
> >>>> Here are the steps I took to run the sample:
> >>>>
> >>>> 1) Build latest blog sample in Aries
> >>>> 2) Build latest Geronimo trunk
> >>>> 3) cd plugins/wab/web-tomcat-server/target/assembly (or
> >>>> web-jetty-server if you prefer)
> >>>> 4) Create database for blog sample using blogDB.sql from blog sample:
> >>>>
> >>>> java -cp
> >>>>
> repository/org/apache/geronimo/bundles/derby-all/10.4.2.0-SNAPSHOT/derby-all-10.4.2.0-SNAPSHOT.jar
> >>>> org.apache.derby.tools.ij
> >>>> <aries>/samples/blog-sample/blog-assembly/target/blogDB.sql
> >>>>
> >>>> 5) Move created blogDB directory to
> >>>> plugins/wab/web-tomcat-server/target/assembly/var/derby
> >>>>
> >>>> 6) Start server:
> >>>>
> >>>> ./bin/geronimo -l
> >>>>
> >>>> 7) Install and start all the blog sample bundles (blog-api-1.0.0.jar,
> >>>> blog-persistence-1.0.0.jar, blog-1.0.0.jar, blog-servlet-1.0.0.jar)
> >>>> using the karaf console.
> >>>>
> >>>> 8) Once you start the blog-servlet-1.0.0.jar bundle, the WAB will be
> >>>> deployed and you should be able to access http://localhost:8080/blog.
> >>>> And if everything is running right you should be able to add new blog
> >>>> entries, etc.
> >>>>
> >>>> Enjoy,
> >>>> Jarek
> >>>
> >>
> >>
> >>
> >> --
> >> Best Regards,
> >>
> >> Delos
> >>
> >
> >
> >
> > --
> > Best Regards,
> >
> > Delos
> >
>



-- 
Best Regards,

Delos

Re: rfc66 update

Posted by Jarek Gawor <jg...@gmail.com>.
Delos,

Why do you think a lazy bundle will be deployed twice? I did not test
the code with lazy bundles so It's possible I missed something but I
think the code is right. Once lazy activated WAB is detected, it will
be tracked by the BundleTracker (by returning non-null value in
addingBundle()). And if the state of such tracked bundle changes from
STARTING to ACTIVE, the modifiedBundle() will be called and not
addingBundle(). addingBundle() will be called twice on a lazy bundle
that is not a WAB but such bundle will be safely ignored.

Jarek

On Tue, Jan 26, 2010 at 4:39 AM, Delos <da...@gmail.com> wrote:
> Thanks for your reply!
>
> I still have a concern about lazy activated bundle in current
> implementation. In BundleTrackerCustomizer, a lazy activated bundle will be
> deployed twice(deployed->undeployed->deployed), because of the state
> transition of the bundle. To avoid this, I suggest to create a separated
> BundleTracker and BundleTrackerCustomizer for lazy-activated Starting
> bundles. Then original BundleTrackerCustomizer can only deploy and undeploy
> Active bundle, while the new BundleTrackerCustomizer only deploys the
> lazy-activated Starting bundles.
>
> Any comments?
>
> 2010/1/25 Rick McGuire <ri...@gmail.com>
>>
>> On 1/25/2010 8:06 AM, Delos wrote:
>>
>> It's really great news!
>>
>> But I have some questions about current implementation.Just want to learn
>> more from it.
>>
>> 1) I found only active and starting bundles are taken into account in
>> current implementation. What about resolved bundles?
>>
>> That's the requirement of the RFC66 specification.  Resolution is a
>> requirement for a bundle to transition to the active or starting states, but
>> the extender is not supposed to take action until one of those states is
>> seen.  It's the same way with Blueprint.
>>
>>
>> 2) For lazy activiated bundles, only starting bundles will be deployed.But
>> in RFC 66, it said "A bundle that has a lazy activation policy should not be
>> transitioned to the STARTING state by the web extender unless a request is
>> made that requires a class to be loaded." Does the implementation violate
>> the document?
>>
>> This is a statement that the extender should not explicitly force the
>> bundle into a started state, but rather should leave that transition to one
>> triggered by a class load.  If the processing the extender needs to perform
>> in processing the bundle results in a triggering class load, that's ok.
>>
>>
>> 3) In RFC 66, static content can be requested without starting a WAB. It's
>> not in the TODO file. Do you have any idea for it? I'm not sure if
>> configuration of WAB can become accessible before actually it's started.
>>
>> The note about static content is marked as an optional feature.  For a lot
>> of processing, it would not be possible to achieve deployment without
>> performing a classload.
>>
>>
>> Thanks!
>>
>> 2010/1/24 David Jencks <da...@yahoo.com>
>>>
>>> great news! congratulations!
>>>
>>> david jencks
>>>
>>> On Jan 23, 2010, at 6:55 PM, Jarek Gawor wrote:
>>>
>>>> Hi all,
>>>>
>>>> Today I checked in an initial version of the rfc66 extender that can
>>>> actually deploy WABs with simple servlets and jsps. There is still
>>>> much work to be done (for example updating the Jasper module builder
>>>> to work with Bundles) but simple stuff seems to be working. In fact
>>>> with David's recent JNDI (rfc142) integration work I was able to
>>>> deploy the Aries blog sample in Geronimo.
>>>>
>>>> Here are the steps I took to run the sample:
>>>>
>>>> 1) Build latest blog sample in Aries
>>>> 2) Build latest Geronimo trunk
>>>> 3) cd plugins/wab/web-tomcat-server/target/assembly (or
>>>> web-jetty-server if you prefer)
>>>> 4) Create database for blog sample using blogDB.sql from blog sample:
>>>>
>>>> java -cp
>>>> repository/org/apache/geronimo/bundles/derby-all/10.4.2.0-SNAPSHOT/derby-all-10.4.2.0-SNAPSHOT.jar
>>>> org.apache.derby.tools.ij
>>>> <aries>/samples/blog-sample/blog-assembly/target/blogDB.sql
>>>>
>>>> 5) Move created blogDB directory to
>>>> plugins/wab/web-tomcat-server/target/assembly/var/derby
>>>>
>>>> 6) Start server:
>>>>
>>>> ./bin/geronimo -l
>>>>
>>>> 7) Install and start all the blog sample bundles (blog-api-1.0.0.jar,
>>>> blog-persistence-1.0.0.jar, blog-1.0.0.jar, blog-servlet-1.0.0.jar)
>>>> using the karaf console.
>>>>
>>>> 8) Once you start the blog-servlet-1.0.0.jar bundle, the WAB will be
>>>> deployed and you should be able to access http://localhost:8080/blog.
>>>> And if everything is running right you should be able to add new blog
>>>> entries, etc.
>>>>
>>>> Enjoy,
>>>> Jarek
>>>
>>
>>
>>
>> --
>> Best Regards,
>>
>> Delos
>>
>
>
>
> --
> Best Regards,
>
> Delos
>

Re: rfc66 update

Posted by Delos <da...@gmail.com>.
Thanks for your reply!

I still have a concern about lazy activated bundle in current
implementation. In BundleTrackerCustomizer, a lazy activated bundle will be
deployed twice(deployed->undeployed->deployed), because of the state
transition of the bundle. To avoid this, I suggest to create a separated
BundleTracker and BundleTrackerCustomizer for lazy-activated Starting
bundles. Then original BundleTrackerCustomizer can only deploy and undeploy
Active bundle, while the new BundleTrackerCustomizer only deploys the
lazy-activated Starting bundles.

Any comments?

2010/1/25 Rick McGuire <ri...@gmail.com>

>  On 1/25/2010 8:06 AM, Delos wrote:
>
> It's really great news!
>
> But I have some questions about current implementation.Just want to learn
> more from it.
>
> 1) I found only active and starting bundles are taken into account in
> current implementation. What about resolved bundles?
>
>
> That's the requirement of the RFC66 specification.  Resolution is a
> requirement for a bundle to transition to the active or starting states, but
> the extender is not supposed to take action until one of those states is
> seen.  It's the same way with Blueprint.
>
>
> 2) For lazy activiated bundles, only starting bundles will be deployed.But
> in RFC 66, it said "A bundle that has a lazy activation policy should not be
> transitioned to the STARTING state by the web extender unless a request is
> made that requires a class to be loaded." Does the implementation violate
> the document?
>
>
> This is a statement that the extender should not explicitly force the
> bundle into a started state, but rather should leave that transition to one
> triggered by a class load.  If the processing the extender needs to perform
> in processing the bundle results in a triggering class load, that's ok.
>
>
> 3) In RFC 66, static content can be requested without starting a WAB. It's
> not in the TODO file. Do you have any idea for it? I'm not sure if
> configuration of WAB can become accessible before actually it's started.
>
>
> The note about static content is marked as an optional feature.  For a lot
> of processing, it would not be possible to achieve deployment without
> performing a classload.
>
>
> Thanks!
>
> 2010/1/24 David Jencks <da...@yahoo.com>
>
>> great news! congratulations!
>>
>> david jencks
>>
>>
>> On Jan 23, 2010, at 6:55 PM, Jarek Gawor wrote:
>>
>>  Hi all,
>>>
>>> Today I checked in an initial version of the rfc66 extender that can
>>> actually deploy WABs with simple servlets and jsps. There is still
>>> much work to be done (for example updating the Jasper module builder
>>> to work with Bundles) but simple stuff seems to be working. In fact
>>> with David's recent JNDI (rfc142) integration work I was able to
>>> deploy the Aries blog sample in Geronimo.
>>>
>>> Here are the steps I took to run the sample:
>>>
>>> 1) Build latest blog sample in Aries
>>> 2) Build latest Geronimo trunk
>>> 3) cd plugins/wab/web-tomcat-server/target/assembly (or
>>> web-jetty-server if you prefer)
>>> 4) Create database for blog sample using blogDB.sql from blog sample:
>>>
>>> java -cp
>>> repository/org/apache/geronimo/bundles/derby-all/10.4.2.0-SNAPSHOT/derby-all-10.4.2.0-SNAPSHOT.jar
>>> org.apache.derby.tools.ij
>>> <aries>/samples/blog-sample/blog-assembly/target/blogDB.sql
>>>
>>> 5) Move created blogDB directory to
>>> plugins/wab/web-tomcat-server/target/assembly/var/derby
>>>
>>> 6) Start server:
>>>
>>> ./bin/geronimo -l
>>>
>>> 7) Install and start all the blog sample bundles (blog-api-1.0.0.jar,
>>> blog-persistence-1.0.0.jar, blog-1.0.0.jar, blog-servlet-1.0.0.jar)
>>> using the karaf console.
>>>
>>> 8) Once you start the blog-servlet-1.0.0.jar bundle, the WAB will be
>>> deployed and you should be able to access http://localhost:8080/blog.
>>> And if everything is running right you should be able to add new blog
>>> entries, etc.
>>>
>>> Enjoy,
>>> Jarek
>>>
>>
>>
>
>
> --
> Best Regards,
>
> Delos
>
>
>


-- 
Best Regards,

Delos

Re: rfc66 update

Posted by Rick McGuire <ri...@gmail.com>.
On 1/25/2010 8:06 AM, Delos wrote:
> It's really great news!
>
> But I have some questions about current implementation.Just want to 
> learn more from it.
>
> 1) I found only active and starting bundles are taken into account in 
> current implementation. What about resolved bundles?

That's the requirement of the RFC66 specification.  Resolution is a 
requirement for a bundle to transition to the active or starting states, 
but the extender is not supposed to take action until one of those 
states is seen.  It's the same way with Blueprint.

>
> 2) For lazy activiated bundles, only starting bundles will be 
> deployed.But in RFC 66, it said "A bundle that has a lazy activation 
> policy should not be transitioned to the STARTING state by the web 
> extender unless a request is made that requires a class to be loaded." 
> Does the implementation violate the document?

This is a statement that the extender should not explicitly force the 
bundle into a started state, but rather should leave that transition to 
one triggered by a class load.  If the processing the extender needs to 
perform in processing the bundle results in a triggering class load, 
that's ok.

>
> 3) In RFC 66, static content can be requested without starting a WAB. 
> It's not in the TODO file. Do you have any idea for it? I'm not sure 
> if configuration of WAB can become accessible before actually it's 
> started.

The note about static content is marked as an optional feature.  For a 
lot of processing, it would not be possible to achieve deployment 
without performing a classload.

>
> Thanks!
>
> 2010/1/24 David Jencks <david_jencks@yahoo.com 
> <ma...@yahoo.com>>
>
>     great news! congratulations!
>
>     david jencks
>
>
>     On Jan 23, 2010, at 6:55 PM, Jarek Gawor wrote:
>
>         Hi all,
>
>         Today I checked in an initial version of the rfc66 extender
>         that can
>         actually deploy WABs with simple servlets and jsps. There is still
>         much work to be done (for example updating the Jasper module
>         builder
>         to work with Bundles) but simple stuff seems to be working. In
>         fact
>         with David's recent JNDI (rfc142) integration work I was able to
>         deploy the Aries blog sample in Geronimo.
>
>         Here are the steps I took to run the sample:
>
>         1) Build latest blog sample in Aries
>         2) Build latest Geronimo trunk
>         3) cd plugins/wab/web-tomcat-server/target/assembly (or
>         web-jetty-server if you prefer)
>         4) Create database for blog sample using blogDB.sql from blog
>         sample:
>
>         java -cp
>         repository/org/apache/geronimo/bundles/derby-all/10.4.2.0-SNAPSHOT/derby-all-10.4.2.0-SNAPSHOT.jar
>         org.apache.derby.tools.ij
>         <aries>/samples/blog-sample/blog-assembly/target/blogDB.sql
>
>         5) Move created blogDB directory to
>         plugins/wab/web-tomcat-server/target/assembly/var/derby
>
>         6) Start server:
>
>         ./bin/geronimo -l
>
>         7) Install and start all the blog sample bundles
>         (blog-api-1.0.0.jar,
>         blog-persistence-1.0.0.jar, blog-1.0.0.jar,
>         blog-servlet-1.0.0.jar)
>         using the karaf console.
>
>         8) Once you start the blog-servlet-1.0.0.jar bundle, the WAB
>         will be
>         deployed and you should be able to access
>         http://localhost:8080/blog.
>         And if everything is running right you should be able to add
>         new blog
>         entries, etc.
>
>         Enjoy,
>         Jarek
>
>
>
>
>
> -- 
> Best Regards,
>
> Delos


Re: rfc66 update

Posted by Delos <da...@gmail.com>.
It's really great news!

But I have some questions about current implementation.Just want to learn
more from it.

1) I found only active and starting bundles are taken into account in
current implementation. What about resolved bundles?

2) For lazy activiated bundles, only starting bundles will be deployed.But
in RFC 66, it said "A bundle that has a lazy activation policy should not be
transitioned to the STARTING state by the web extender unless a request is
made that requires a class to be loaded." Does the implementation violate
the document?

3) In RFC 66, static content can be requested without starting a WAB. It's
not in the TODO file. Do you have any idea for it? I'm not sure if
configuration of WAB can become accessible before actually it's started.

Thanks!

2010/1/24 David Jencks <da...@yahoo.com>

> great news! congratulations!
>
> david jencks
>
>
> On Jan 23, 2010, at 6:55 PM, Jarek Gawor wrote:
>
>  Hi all,
>>
>> Today I checked in an initial version of the rfc66 extender that can
>> actually deploy WABs with simple servlets and jsps. There is still
>> much work to be done (for example updating the Jasper module builder
>> to work with Bundles) but simple stuff seems to be working. In fact
>> with David's recent JNDI (rfc142) integration work I was able to
>> deploy the Aries blog sample in Geronimo.
>>
>> Here are the steps I took to run the sample:
>>
>> 1) Build latest blog sample in Aries
>> 2) Build latest Geronimo trunk
>> 3) cd plugins/wab/web-tomcat-server/target/assembly (or
>> web-jetty-server if you prefer)
>> 4) Create database for blog sample using blogDB.sql from blog sample:
>>
>> java -cp
>> repository/org/apache/geronimo/bundles/derby-all/10.4.2.0-SNAPSHOT/derby-all-10.4.2.0-SNAPSHOT.jar
>> org.apache.derby.tools.ij
>> <aries>/samples/blog-sample/blog-assembly/target/blogDB.sql
>>
>> 5) Move created blogDB directory to
>> plugins/wab/web-tomcat-server/target/assembly/var/derby
>>
>> 6) Start server:
>>
>> ./bin/geronimo -l
>>
>> 7) Install and start all the blog sample bundles (blog-api-1.0.0.jar,
>> blog-persistence-1.0.0.jar, blog-1.0.0.jar, blog-servlet-1.0.0.jar)
>> using the karaf console.
>>
>> 8) Once you start the blog-servlet-1.0.0.jar bundle, the WAB will be
>> deployed and you should be able to access http://localhost:8080/blog.
>> And if everything is running right you should be able to add new blog
>> entries, etc.
>>
>> Enjoy,
>> Jarek
>>
>
>


-- 
Best Regards,

Delos

Re: rfc66 update

Posted by David Jencks <da...@yahoo.com>.
great news! congratulations!

david jencks

On Jan 23, 2010, at 6:55 PM, Jarek Gawor wrote:

> Hi all,
>
> Today I checked in an initial version of the rfc66 extender that can
> actually deploy WABs with simple servlets and jsps. There is still
> much work to be done (for example updating the Jasper module builder
> to work with Bundles) but simple stuff seems to be working. In fact
> with David's recent JNDI (rfc142) integration work I was able to
> deploy the Aries blog sample in Geronimo.
>
> Here are the steps I took to run the sample:
>
> 1) Build latest blog sample in Aries
> 2) Build latest Geronimo trunk
> 3) cd plugins/wab/web-tomcat-server/target/assembly (or
> web-jetty-server if you prefer)
> 4) Create database for blog sample using blogDB.sql from blog sample:
>
> java -cp repository/org/apache/geronimo/bundles/derby-all/10.4.2.0- 
> SNAPSHOT/derby-all-10.4.2.0-SNAPSHOT.jar
> org.apache.derby.tools.ij
> <aries>/samples/blog-sample/blog-assembly/target/blogDB.sql
>
> 5) Move created blogDB directory to
> plugins/wab/web-tomcat-server/target/assembly/var/derby
>
> 6) Start server:
>
> ./bin/geronimo -l
>
> 7) Install and start all the blog sample bundles (blog-api-1.0.0.jar,
> blog-persistence-1.0.0.jar, blog-1.0.0.jar, blog-servlet-1.0.0.jar)
> using the karaf console.
>
> 8) Once you start the blog-servlet-1.0.0.jar bundle, the WAB will be
> deployed and you should be able to access http://localhost:8080/blog.
> And if everything is running right you should be able to add new blog
> entries, etc.
>
> Enjoy,
> Jarek