Re: System property replacement in deployment descriptors

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: System property replacement in deployment descriptors

Oleg Kulikov
Hi Jaikiran,

Can you explain more details about your vision of the property replacement task. In general it is interested how deep it should be shared between different substems where xml descriptors are used. Should it be a common parsing utility with description which properies allow expressions or it may be just a simple utility method shared between parsing methods?

-- Oleg.

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: System property replacement in deployment descriptors

Jaikiran Pai
Oleg, sorry about the late response.

Currently in AS7 we have xml parsing happening within the AS7 code base
for the following xmls:

1) The standalone*.xml/domain*.xml
2) The jboss-deployment-structure.xml
3) The jboss-ejb-client.xml
4) The jboss-pojo xml
5) The jboss-service.xml

and probably a few others. Then we have parsers in other projects
outside of AS7 codebase which deal with (for example):

1) The spec specified EE descriptors like ejb-jar.xml, web.xml,
application.xml
2) JBoss specific (EE) deployment descriptors for the deployments like
jboss-web.xml, jboss-app.xml, jboss-ejb3.xml

These have their own set of parsers.

So obviously trying to _share_ the same system property replacement
logic utility class, between these projects isn't going to work out. And
since it's just going to be one since class which is going to parse and
replace the system property, I think we should just create it in the AS7
code base and let the parsers in the AS7 code base use that (whichever
parser wants it). The other projects (like jboss-metadata) can use their
own (actually we just added one sometime back to support system property
replacement for "distinct-name" element in the JBoss specific EE
descriptors).

By the way, the DMR project has a class which handles this property
replacement (in that project). You might want to borrow that relevant
code
https://github.com/jbossas/jboss-dmr/blob/master/src/main/java/org/jboss/dmr/ExpressionValue.java#L110.

-Jaikiran

On Friday 10 February 2012 02:31 PM, Oleg Kulikov wrote:

> Hi Jaikiran,
>
> Can you explain more details about your vision of the property
> replacement task. In general it is interested how deep it should be
> shared between different substems where xml descriptors are used.
> Should it be a common parsing utility with description which properies
> allow expressions or it may be just a simple utility method shared
> between parsing methods?
>
> -- Oleg.
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: System property replacement in deployment descriptors

Ales Justin
Oleg, sorry about the late response.

Currently in AS7 we have xml parsing happening within the AS7 code base
for the following xmls:

1) The standalone*.xml/domain*.xml
2) The jboss-deployment-structure.xml
3) The jboss-ejb-client.xml
4) The jboss-pojo xml

jboss-beans.xml


Unless there is some other jboss-pojo.xml?

5) The jboss-service.xml

and probably a few others. Then we have parsers in other projects
outside of AS7 codebase which deal with (for example):

1) The spec specified EE descriptors like ejb-jar.xml, web.xml,
application.xml
2) JBoss specific (EE) deployment descriptors for the deployments like
jboss-web.xml, jboss-app.xml, jboss-ejb3.xml

These have their own set of parsers.

So obviously trying to _share_ the same system property replacement
logic utility class, between these projects isn't going to work out. And
since it's just going to be one since class which is going to parse and
replace the system property, I think we should just create it in the AS7
code base and let the parsers in the AS7 code base use that (whichever
parser wants it). The other projects (like jboss-metadata) can use their
own (actually we just added one sometime back to support system property
replacement for "distinct-name" element in the JBoss specific EE
descriptors).

By the way, the DMR project has a class which handles this property
replacement (in that project). You might want to borrow that relevant
code
https://github.com/jbossas/jboss-dmr/blob/master/src/main/java/org/jboss/dmr/ExpressionValue.java#L110.

-Jaikiran

On Friday 10 February 2012 02:31 PM, Oleg Kulikov wrote:
Hi Jaikiran,

Can you explain more details about your vision of the property
replacement task. In general it is interested how deep it should be
shared between different substems where xml descriptors are used.
Should it be a common parsing utility with description which properies
allow expressions or it may be just a simple utility method shared
between parsing methods?

-- Oleg.


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: System property replacement in deployment descriptors

Jaikiran Pai
On Wednesday 15 February 2012 09:53 PM, Ales Justin wrote:

>> Oleg, sorry about the late response.
>>
>> Currently in AS7 we have xml parsing happening within the AS7 code base
>> for the following xmls:
>>
>> 1) The standalone*.xml/domain*.xml
>> 2) The jboss-deployment-structure.xml
>> 3) The jboss-ejb-client.xml
>> 4) The jboss-pojo xml
>
> jboss-beans.xml
>
> *
> https://github.com/jbossas/jboss-as/blob/master/pojo/src/main/java/org/jboss/as/pojo/KernelDeploymentParsingProcessor.java
>
> Unless there is some other jboss-pojo.xml?
Oh yeah, I actually meant jboss-beans.xml but the xsd is named
jboss-pojo.xsd
https://github.com/jbossas/jboss-as/blob/master/build/src/main/resources/docs/schema/jboss-pojo_7_0.xsd.
That's what caused the confusion.

-Jaikiran
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: System property replacement in deployment descriptors

Brian Stansberry
In reply to this post by Jaikiran Pai
Comments in-line:

On 2/15/12 10:03 AM, Jaikiran Pai wrote:
> Oleg, sorry about the late response.
>
> Currently in AS7 we have xml parsing happening within the AS7 code base
> for the following xmls:
>
> 1) The standalone*.xml/domain*.xml

These files (and host.xml) should be excluded from this effort. They
have significantly different requirements, primarily related to the need
to maintain and write back the unresolved value.

> 2) The jboss-deployment-structure.xml
> 3) The jboss-ejb-client.xml
> 4) The jboss-pojo xml
> 5) The jboss-service.xml
>
> and probably a few others. Then we have parsers in other projects
> outside of AS7 codebase which deal with (for example):
>
> 1) The spec specified EE descriptors like ejb-jar.xml, web.xml,
> application.xml
> 2) JBoss specific (EE) deployment descriptors for the deployments like
> jboss-web.xml, jboss-app.xml, jboss-ejb3.xml
>
> These have their own set of parsers.
>
> So obviously trying to _share_ the same system property replacement
> logic utility class, between these projects isn't going to work out. And
> since it's just going to be one since class which is going to parse and
> replace the system property, I think we should just create it in the AS7
> code base and let the parsers in the AS7 code base use that (whichever
> parser wants it). The other projects (like jboss-metadata) can use their
> own (actually we just added one sometime back to support system property
> replacement for "distinct-name" element in the JBoss specific EE
> descriptors).
>
> By the way, the DMR project has a class which handles this property
> replacement (in that project). You might want to borrow that relevant
> code
> https://github.com/jbossas/jboss-dmr/blob/master/src/main/java/org/jboss/dmr/ExpressionValue.java#L110.
>

In a commment on the JIRA I pointed out the old jboss-common-core
parsing method. But Jaikiran is right to highlight the DMR method as a
better choice. Scott Stark added logic to it for resolving against the
VM environment variables (System.getenv()) and not just the system
properties.

> -Jaikiran
>
> On Friday 10 February 2012 02:31 PM, Oleg Kulikov wrote:
>> Hi Jaikiran,
>>
>> Can you explain more details about your vision of the property
>> replacement task. In general it is interested how deep it should be
>> shared between different substems where xml descriptors are used.
>> Should it be a common parsing utility with description which properies
>> allow expressions or it may be just a simple utility method shared
>> between parsing methods?
>>
>> -- Oleg.
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: System property replacement in deployment descriptors

Oleg Kulikov
Thanks, I understand the issue now.

--Oleg

15 февраля 2012 г. 19:35 пользователь Brian Stansberry <[hidden email]> написал:
Comments in-line:

On 2/15/12 10:03 AM, Jaikiran Pai wrote:
> Oleg, sorry about the late response.
>
> Currently in AS7 we have xml parsing happening within the AS7 code base
> for the following xmls:
>
> 1) The standalone*.xml/domain*.xml

These files (and host.xml) should be excluded from this effort. They
have significantly different requirements, primarily related to the need
to maintain and write back the unresolved value.

> 2) The jboss-deployment-structure.xml
> 3) The jboss-ejb-client.xml
> 4) The jboss-pojo xml
> 5) The jboss-service.xml
>
> and probably a few others. Then we have parsers in other projects
> outside of AS7 codebase which deal with (for example):
>
> 1) The spec specified EE descriptors like ejb-jar.xml, web.xml,
> application.xml
> 2) JBoss specific (EE) deployment descriptors for the deployments like
> jboss-web.xml, jboss-app.xml, jboss-ejb3.xml
>
> These have their own set of parsers.
>
> So obviously trying to _share_ the same system property replacement
> logic utility class, between these projects isn't going to work out. And
> since it's just going to be one since class which is going to parse and
> replace the system property, I think we should just create it in the AS7
> code base and let the parsers in the AS7 code base use that (whichever
> parser wants it). The other projects (like jboss-metadata) can use their
> own (actually we just added one sometime back to support system property
> replacement for "distinct-name" element in the JBoss specific EE
> descriptors).
>
> By the way, the DMR project has a class which handles this property
> replacement (in that project). You might want to borrow that relevant
> code
> https://github.com/jbossas/jboss-dmr/blob/master/src/main/java/org/jboss/dmr/ExpressionValue.java#L110.
>

In a commment on the JIRA I pointed out the old jboss-common-core
parsing method. But Jaikiran is right to highlight the DMR method as a
better choice. Scott Stark added logic to it for resolving against the
VM environment variables (System.getenv()) and not just the system
properties.

> -Jaikiran
>
> On Friday 10 February 2012 02:31 PM, Oleg Kulikov wrote:
>> Hi Jaikiran,
>>
>> Can you explain more details about your vision of the property
>> replacement task. In general it is interested how deep it should be
>> shared between different substems where xml descriptors are used.
>> Should it be a common parsing utility with description which properies
>> allow expressions or it may be just a simple utility method shared
>> between parsing methods?
>>
>> -- Oleg.
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: System property replacement in deployment descriptors

Scott Marlow
How will property replacement work in a domain?  Will we need a domain
level property list that is checked (at substitution time?)

On 02/15/2012 12:04 PM, Oleg Kulikov wrote:

> Thanks, I understand the issue now.
>
> --Oleg
>
> 15 февраля 2012 г. 19:35 пользователь Brian Stansberry
> <[hidden email] <mailto:[hidden email]>> написал:
>
>     Comments in-line:
>
>     On 2/15/12 10:03 AM, Jaikiran Pai wrote:
>      > Oleg, sorry about the late response.
>      >
>      > Currently in AS7 we have xml parsing happening within the AS7
>     code base
>      > for the following xmls:
>      >
>      > 1) The standalone*.xml/domain*.xml
>
>     These files (and host.xml) should be excluded from this effort. They
>     have significantly different requirements, primarily related to the need
>     to maintain and write back the unresolved value.
>
>      > 2) The jboss-deployment-structure.xml
>      > 3) The jboss-ejb-client.xml
>      > 4) The jboss-pojo xml
>      > 5) The jboss-service.xml
>      >
>      > and probably a few others. Then we have parsers in other projects
>      > outside of AS7 codebase which deal with (for example):
>      >
>      > 1) The spec specified EE descriptors like ejb-jar.xml, web.xml,
>      > application.xml
>      > 2) JBoss specific (EE) deployment descriptors for the deployments
>     like
>      > jboss-web.xml, jboss-app.xml, jboss-ejb3.xml
>      >
>      > These have their own set of parsers.
>      >
>      > So obviously trying to _share_ the same system property replacement
>      > logic utility class, between these projects isn't going to work
>     out. And
>      > since it's just going to be one since class which is going to
>     parse and
>      > replace the system property, I think we should just create it in
>     the AS7
>      > code base and let the parsers in the AS7 code base use that
>     (whichever
>      > parser wants it). The other projects (like jboss-metadata) can
>     use their
>      > own (actually we just added one sometime back to support system
>     property
>      > replacement for "distinct-name" element in the JBoss specific EE
>      > descriptors).
>      >
>      > By the way, the DMR project has a class which handles this property
>      > replacement (in that project). You might want to borrow that relevant
>      > code
>      >
>     https://github.com/jbossas/jboss-dmr/blob/master/src/main/java/org/jboss/dmr/ExpressionValue.java#L110.
>      >
>
>     In a commment on the JIRA I pointed out the old jboss-common-core
>     parsing method. But Jaikiran is right to highlight the DMR method as a
>     better choice. Scott Stark added logic to it for resolving against the
>     VM environment variables (System.getenv()) and not just the system
>     properties.
>
>      > -Jaikiran
>      >
>      > On Friday 10 February 2012 02:31 PM, Oleg Kulikov wrote:
>      >> Hi Jaikiran,
>      >>
>      >> Can you explain more details about your vision of the property
>      >> replacement task. In general it is interested how deep it should be
>      >> shared between different substems where xml descriptors are used.
>      >> Should it be a common parsing utility with description which
>     properies
>      >> allow expressions or it may be just a simple utility method shared
>      >> between parsing methods?
>      >>
>      >> -- Oleg.
>      >>
>      >>
>      >> _______________________________________________
>      >> jboss-as7-dev mailing list
>      >> [hidden email] <mailto:[hidden email]>
>      >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>      >
>      > _______________________________________________
>      > jboss-as7-dev mailing list
>      > [hidden email] <mailto:[hidden email]>
>      > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>     --
>     Brian Stansberry
>     Principal Software Engineer
>     JBoss by Red Hat
>     _______________________________________________
>     jboss-as7-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: System property replacement in deployment descriptors

Brian Stansberry
No, it's part of the task of the domain infrastructure to ensure that
system properties are set on the servers being managed. So, a server in
a managed domain will handle this the same as a standalone server.

The various <system-property> elements in domain.xml/host.xml let users
control what properties are set on what servers.

On 3/1/12 11:01 AM, Scott Marlow wrote:

> How will property replacement work in a domain? Will we need a domain
> level property list that is checked (at substitution time?)
>
> On 02/15/2012 12:04 PM, Oleg Kulikov wrote:
>> Thanks, I understand the issue now.
>>
>> --Oleg
>>
>> 15 февраля 2012 г. 19:35 пользователь Brian Stansberry
>> <[hidden email] <mailto:[hidden email]>>
>> написал:
>>
>> Comments in-line:
>>
>> On 2/15/12 10:03 AM, Jaikiran Pai wrote:
>> > Oleg, sorry about the late response.
>> >
>> > Currently in AS7 we have xml parsing happening within the AS7
>> code base
>> > for the following xmls:
>> >
>> > 1) The standalone*.xml/domain*.xml
>>
>> These files (and host.xml) should be excluded from this effort. They
>> have significantly different requirements, primarily related to the need
>> to maintain and write back the unresolved value.
>>
>> > 2) The jboss-deployment-structure.xml
>> > 3) The jboss-ejb-client.xml
>> > 4) The jboss-pojo xml
>> > 5) The jboss-service.xml
>> >
>> > and probably a few others. Then we have parsers in other projects
>> > outside of AS7 codebase which deal with (for example):
>> >
>> > 1) The spec specified EE descriptors like ejb-jar.xml, web.xml,
>> > application.xml
>> > 2) JBoss specific (EE) deployment descriptors for the deployments
>> like
>> > jboss-web.xml, jboss-app.xml, jboss-ejb3.xml
>> >
>> > These have their own set of parsers.
>> >
>> > So obviously trying to _share_ the same system property replacement
>> > logic utility class, between these projects isn't going to work
>> out. And
>> > since it's just going to be one since class which is going to
>> parse and
>> > replace the system property, I think we should just create it in
>> the AS7
>> > code base and let the parsers in the AS7 code base use that
>> (whichever
>> > parser wants it). The other projects (like jboss-metadata) can
>> use their
>> > own (actually we just added one sometime back to support system
>> property
>> > replacement for "distinct-name" element in the JBoss specific EE
>> > descriptors).
>> >
>> > By the way, the DMR project has a class which handles this property
>> > replacement (in that project). You might want to borrow that relevant
>> > code
>> >
>> https://github.com/jbossas/jboss-dmr/blob/master/src/main/java/org/jboss/dmr/ExpressionValue.java#L110.
>>
>> >
>>
>> In a commment on the JIRA I pointed out the old jboss-common-core
>> parsing method. But Jaikiran is right to highlight the DMR method as a
>> better choice. Scott Stark added logic to it for resolving against the
>> VM environment variables (System.getenv()) and not just the system
>> properties.
>>
>> > -Jaikiran
>> >
>> > On Friday 10 February 2012 02:31 PM, Oleg Kulikov wrote:
>> >> Hi Jaikiran,
>> >>
>> >> Can you explain more details about your vision of the property
>> >> replacement task. In general it is interested how deep it should be
>> >> shared between different substems where xml descriptors are used.
>> >> Should it be a common parsing utility with description which
>> properies
>> >> allow expressions or it may be just a simple utility method shared
>> >> between parsing methods?
>> >>
>> >> -- Oleg.
>> >>
>> >>
>> >> _______________________________________________
>> >> jboss-as7-dev mailing list
>> >> [hidden email] <mailto:[hidden email]>
>> >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> >
>> > _______________________________________________
>> > jboss-as7-dev mailing list
>> > [hidden email] <mailto:[hidden email]>
>> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>> --
>> Brian Stansberry
>> Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email] <mailto:[hidden email]>
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev