Now, the feature should be considered ahead of time because design for the feature seemed to have a relationship with some issues(for example, Glassfish-19215).
If implementing the feature, a user maybe use the following deploying command to specify serviceCriteria,
asadmin deploy --type=osgi --properties serviceprops=(name=lang,value=__CH) e:\test_sample1.jar
There is a important topic that we should make OSGiServiceExtension can obtain current deployed bundle's serviceprops which is from "--properties". However, OSGiServiceExtension is not related to DeploymentContext at all.
So, I consider a solution which is similar to how OSGiEJBDeployer obtains OSGiApplicationInfo, that is to say, on the first deploying phrase, we register serviceprops as a OSGi service once finding serviceprops, then, in OSGiServiceExtension, getting current bundle's serviceprops by OSGi service.
Then, the reason that I say the feature maybe have a relationship with Glassfish-19215 is that whether having some design possibility rather than registering serviceprops as a OSGi service.